:strip_exif()/i/2002897482.png?f=thumbmini)
:strip_icc():strip_exif()/u/220376/twitchy_ava60.jpg?f=community)
:strip_exif()/u/3443/lizard.gif?f=community)
:strip_icc():strip_exif()/u/72351/Toon_en_Len%25202015-02-02%252070x69.jpg?f=community)
The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
:strip_icc():strip_exif()/u/144633/crop643e593ea432f_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/53754/crop5f96dc1010e28_cropped.jpeg?f=community)
Zie afbeelding:
Dit is het resultaat van anonymous mode waarbij alleen de "live anonymous statistics" te zien zijn. Als ik in deze modus pihole herstart staan alle tellers weer op 0 => deze "live anonymous statistics" worden blijkbaar niet opgeslagen en herladen na de herstart.
In alle andere privacy modi lijkt er een query database te worden bijgehouden voor een maxdb-aantal dagen. Bij een restart worden diezelfde grafieken weer gevuld met de cijfers van de laatste 24 uur. Dat had ik ook verwacht met de "live anonymous statistics".
:fill(white):strip_exif()/f/image/d4bshvpLL4Q1pVPiySxGY5AZ.png?f=user_large)
[ Voor 13% gewijzigd door Airw0lf op 25-05-2024 22:48 ]
makes it run like clockwork
:strip_icc():strip_exif()/u/99951/Eye.jpg?f=community)
Dan wel even je firewall goed africhten, want dan staat direct alles open. En mogelijk dat je dan tegen port-in-use issues aanloopt. bv de management interface draait standaard op port 80, dus dan moet die wel vrij zijn.:
[...]
Mijn 0,100 Euro: niet moeilijk doen en gewoon host mode gebruiken!
/u/658914/crop5f7a5ee826414_cropped.png?f=community)
Welke ik al gezien heb als stub resolver voor systemd distros:
systemd-resolved
dnsmasq
connmand
Welke dus allemaal gaan conflicteren als de Docker host of default bridge netwerk driver wordt toegepast.
De bare metal Pi-hole installer kan systemd-resolved en dnsmasq detecteren en het stub resolver gedeelte uitschakelen:
$ curl -sSL https://install.pi-hole.net | grep 'systemd-resolved\|dnsmasq'
[..]
# Systemd-resolved's DNSStubListener and dnsmasq can't share port 53.
printf " %b Testing if systemd-resolved is enabled\\n" "${INFO}"
if check_service_active "systemd-resolved"; then
printf " %b %b Testing if systemd-resolved DNSStub-Listener is active" "${OVER}" "${INFO}"
# Note that this breaks dns functionality on host until dnsmasq/ftl are up and running
printf "%b %b Disabling systemd-resolved DNSStubListener" "${OVER}" "${TICK}"
printf " and restarting systemd-resolved\\n"
systemctl reload-or-restart systemd-resolved
# Check if dnsmasq is present. If so, disable it and back up any possible
disable_dnsmasq
[..]Dit detecteren lukt natuurlijk niet als Pi-hole in Docker draait.
En alles kan misgaan natuurlijk
There are only 10 types of people in the world: those who understand binary, and those who don't
Ja, want ik heb op een Raspberry Pi nog een tweede Pihole draaien.
Inderdaad, die port mappings zouden genoeg moeten zijn...
Thanks!
Dat voelt als falen ;-) Ik vind (en geloof) dat het zonder host-mode moet kunnen werken:
[...]
Mijn 0,100 Euro: niet moeilijk doen en gewoon host mode gebruiken!
Thanks! Het meeste had ik al gelezen. Unbound moet ik echt nog induiken.
Systemd-Resolved. Die had ik nu disabled. Maar het probleem lijkt ergens anders te zitten.
Niet op dit soort berichten ingaan, reacties op verwijdere posts ook in deze post verwijderd.
Nee, dat klopt, vandaar dat ik ook vraag wat het betekent.
Het probleem lijkt er vooralsnog nu meer in te zitten dat mijn USG de configuratie niet goed opslaat, waardoor de DNS Server nog altijd naar mijn oude geMACVLANde IP van de PiHole wijzen en niet naar de andere. Daar moet ik dus nog even verder induiken.
[ Voor 26% gewijzigd door Yariva op 24-06-2024 12:49 ]
Klinkt als "beleving"... voor mij voelt iets anders dan host mode juist als falen.:
[...]
Dat voelt als falen ;-) Ik vind (en geloof) dat het zonder host-mode moet kunnen werken
Immers - met een Docker container hoef ik nauwelijks na te denken over wat er precies aan elkaar geknoopt wordt - Docker regelt het...
makes it run like clockwork
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
En daarom is host mode eigenlijk een slecht idee:
[...]
Klinkt als "beleving"... voor mij voelt iets anders dan host mode juist als falen.
Immers - met een Docker container hoef ik nauwelijks na te denken over wat er precies aan elkaar geknoopt wordt - Docker regelt het...
. Dan mis je toch nét dat beetje isolatie op netwerkgebied wat Docker voor je regelt. Want zo'n Pi Hole kan dan ook eenvoudig langs mechanismes zoals UFW (voor zover ik weet). Maar voor broadcasting en discovery zoals een DHCP server kun je bijna niet anders. Dat staat ook (als comment) in de gelinkte repo:code:
1
| # For DHCP it is recommended to remove these ports and instead add: network_mode: "host" |
IMHO is the way to go een dubbel netwerk in Compose. En dan een combinatie van een intern netwerk en een ipvlan netwerk. Die laatste kun je heel eenvoudig aanmaken:
Bash:
1
2
3
4
| docker network create -d ipvlan \ --subnet=192.168.1.0/24 \ --gateway=192.168.1.1 \ -o parent=enp3s0 br0 |
Dit maakt een ipvlan netwerk aan met de naam br0 op de 192.168.1.0/24 range. Dit is de range van mijn DHCP server. Hier kan ik dan relatief eenvoudige statische toewijzingen doen. Als ik dit dan toepas in Compose (met Unbound) dan ziet er dat ongeveer zo uit in Compose:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| services: pihole: container_name: pihole image: pihole/pihole:latest restart: unless-stopped networks: vlan: ipv4_address: 192.168.1.4 private: environment: TZ: 'Europe/Amsterdam' volumes: - './etc-pihole:/etc/pihole' - './etc-dnsmasq.d:/etc/dnsmasq.d' unbound: container_name: pihole-unbound image: klutchell/unbound:latest restart: on-failure networks: private: ipv4_address: 10.100.20.200 networks: vlan: name: br0 external: true private: name: pihole-network ipam: driver: default config: - subnet: 10.100.20.0/24 |
Je kunt namelijk een container aan meerdere netwerken koppelen. In dit geval geef ik het interne netwerk ook nog een expliciete ip range mee zodat ik zeker weet dat Unbound op een bepaald adres beschikbaar is. Dat doe ik normaal niet en dan routeer ik op hostname van de container. Ik wilde dit eigenlijk hier ook doen, maar dat kreeg ik niet werkend in Adguard Home* omdat die blijkbaar de Docker DNS niet (correct) oppikt. Wel kun je Pi-Hole met bovenstaande laten verwijzen naar 10.100.20.200 als upstream DNS.
IPVlan is overigens net zo beroerd als host mode qua security. Die zet in principe host mode aan op het IP adres wat je de container geeft. Echter vind ik dit toch een beter idee omdat er dan nog netwerkisolatie plaatsvind op adresniveau. Dat heb je niet als je meerdere services één adres laat delen. Ook heb je geen kans op poortconflicten.
Er zijn natuurlijk meerdere wegen naar Rome. Ik vind bovenstaande manier met name prettig omdat ik toch een scheiding creëer met Docker, maar toch applicaties op IP adres kan benaderen als ik dat nodig heb. Of eigenlijk op hostname, want in mijn router heb ik nagenoeg alle Docker exposed IP's gemapt naar hostnames met statische DHCP reserveringen.
* Ik gebruik inmiddels geen Pi hole meer, maar Adguard Home, maar de concepten blijven hetzelfde
Zeker beleving!:
[...]
Klinkt als "beleving"... voor mij voelt iets anders dan host mode juist als falen.
Immers - met een Docker container hoef ik nauwelijks na te denken over wat er precies aan elkaar geknoopt wordt - Docker regelt het...
Één van de redenen om van MACVLAN naar bridge networks over te stappen is voor mij juist om er voor te zorgen dat er meer isolatie is.
Natuurlijk kom je dan ook op de discussie of je je apps als losse stacks draait, óf dat je zaken groepeert (zoals ik, ik gebruik één Postgres voor meerdere services). Maar dat is allemaal niet voor hier
Ik doe geen DHCP via PiHole, dus daarom heb ik IPVLAN of MACVLAN ook niet nodig.:
[...]
En daarom is host mode eigenlijk een slecht idee
code:
IMHO is the way to go een dubbel netwerk in Compose. En dan een combinatie van een intern netwerk en een ipvlan netwerk. Die laatste kun je heel eenvoudig aanmaken:
Bash:
Dit maakt een ipvlan netwerk aan met de naam br0 op de 192.168.1.0/24 range. Dit is de range van mijn DHCP server. Hier kan ik dan relatief eenvoudige statische toewijzingen doen. Als ik dit dan toepas in Compose (met Unbound) dan ziet er dat ongeveer zo uit in Compose:
YAML:
Je kunt namelijk een container aan meerdere netwerken koppelen. In dit geval geef ik het interne netwerk ook nog een expliciete ip range mee zodat ik zeker weet dat Unbound op een bepaald adres beschikbaar is. Dat doe ik normaal niet en dan routeer ik op hostname van de container. Ik wilde dit eigenlijk hier ook doen, maar dat kreeg ik niet werkend in Adguard Home* omdat die blijkbaar de Docker DNS niet (correct) oppikt. Wel kun je Pi-Hole met bovenstaande laten verwijzen naar 10.100.20.200 als upstream DNS.
IPVlan is overigens net zo beroerd als host mode qua security. Die zet in principe host mode aan op het IP adres wat je de container geeft. Echter vind ik dit toch een beter idee omdat er dan nog netwerkisolatie plaatsvind op adresniveau. Dat heb je niet als je meerdere services één adres laat delen. Ook heb je geen kans op poortconflicten.
Er zijn natuurlijk meerdere wegen naar Rome. Ik vind bovenstaande manier met name prettig omdat ik toch een scheiding creëer met Docker, maar toch applicaties op IP adres kan benaderen als ik dat nodig heb. Of eigenlijk op hostname, want in mijn router heb ik nagenoeg alle Docker exposed IP's gemapt naar hostnames met statische DHCP reserveringen.
* Ik gebruik inmiddels geen Pi hole meer, maar Adguard Home, maar de concepten blijven hetzelfde
Wat is de reden dat je geen PiHole meer gebruikt?
Probleem lijkt overigens opgelost te zijn... Het lag niet aan Docker, het lag aan Unifi...
Ik had in de Unifi Network Application netjes alles omgezet en volgens de UI wees alles naar de juiste IP's...
Echter stonden de port-forwards "achter de schermen" nog naar de oude IP te wijzen en de DNS Resolvers ook... Dus dan gaan dingen stuk...
Dat heeft niets met elkaar te maken
. Alleen als je DHCP gebruikt, wordt het aanbevolen om direct aan IP te binden vanwege netwerk broadcasts. Of dat via host mode, of een VLAN driver is, is dan om het even. Een bridge is eigenlijk ook maar een vlan, maar dan met complete isolatie van het netwerk van de Docker host.Omdat destijds (jaren geleden toen ik switchte) Adguard Home efficiënter werkte en er betere Docker ondersteuning was. Maar verschillen tussen de twee pakketten zijn enorm klein en is nu geen reden meer om te switchen.
Aan een IP heb je niks met de initiele DHCP discover broadcast.:
Dat heeft niets met elkaar te maken
Dat gaat via het MAC (0c:2f:b0:XX:XX:XX onder):
$ sudo tcpdump -ntvvvi any udp port 67 or udp port 68
[..]
IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 336)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 0c:2f:b0:XX:XX:XX, length 308, xid 0xac6549ab, Flags [none] (0x0000)
[..]
IP (tos 0xc0, ttl 64, id 46875, offset 0, flags [none], proto UDP (17), length 346)
10.0.0.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 318, xid 0x2615a79f, Flags [Broadcast] (0x8000)Een broadcast reikt zover als het broadcast domain en is niet aan een unicast IP of subnet gebonden:
Wikipedia: Broadcast domain
De officiele docs laten een paar mogelijkheden zien:
https://docs.pi-hole.net/docker/dhcp/
EDIT: Die verdraaide documentatie elke keer
[ Voor 12% gewijzigd door deHakkelaar op 24-06-2024 21:43 . Reden: + reply ]
There are only 10 types of people in the world: those who understand binary, and those who don't
@deHakkelaar Weer iets geleerd . Het is alweer jaren geleden dat ik Pi-Hole (of AdGuard Home) als DHCP heb gebruikt.
. Het is alweer jaren geleden dat ik Pi-Hole (of AdGuard Home) als DHCP heb gebruikt.
@alex3305 , en ik heb alleen ervaring met bare metal Pi-hole als DHCP
[ Voor 3% gewijzigd door deHakkelaar op 24-06-2024 21:29 ]
There are only 10 types of people in the world: those who understand binary, and those who don't
Ja, sorry, was iets te kort door de bocht:
[...]
Dat heeft niets met elkaar te maken
Dank!Yes, heb ik nu ook gedaan, alleen dan via een pihole.conf in /etc/systemd/resolved.conf.d, wat ik uit de AdGuard Home documentatie heb gepikt
Op dit moment wordt de pihole-log volgepompt met de volgende meldingen:
Deze melding komt van een switch die onbereikbaar is geworden na een tikfout bij het aanpassen van het IP adres.
Ik ben deze nog nooit tegengekomen en heb daarom ook geen idee wat er aan de hand is.
Iemand een idee hoe dit aan te pakken?
code:
1
2
3
4
5
6
7
| Jun 25 18:37:22 dnsmasq-dhcp[125663]: DHCPDECLINE(eth0) 192.168.139.27 c0:c9:e3:0e:7b:bf Jun 25 18:37:47 dnsmasq-dhcp[125663]: DHCPDECLINE(eth0) 192.168.139.28 c0:c9:e3:0e:7b:bf Jun 25 18:38:11 dnsmasq-dhcp[125663]: DHCPDECLINE(eth0) 192.168.139.29 c0:c9:e3:0e:7b:bf Jun 25 18:38:35 dnsmasq-dhcp[125663]: DHCPDECLINE(eth0) 192.168.139.30 c0:c9:e3:0e:7b:bf Jun 25 18:38:59 dnsmasq-dhcp[125663]: DHCPDECLINE(eth0) 192.168.139.31 c0:c9:e3:0e:7b:bf Jun 25 18:39:24 dnsmasq-dhcp[125663]: DHCPDECLINE(eth0) 192.168.139.33 c0:c9:e3:0e:7b:bf Jun 25 18:39:45 dnsmasq-dhcp[125663]: DHCPDECLINE(eth0) 192.168.139.33 c0:c9:e3:0e:7b:bf |
Deze melding komt van een switch die onbereikbaar is geworden na een tikfout bij het aanpassen van het IP adres.
Ik ben deze nog nooit tegengekomen en heb daarom ook geen idee wat er aan de hand is.
Iemand een idee hoe dit aan te pakken?
makes it run like clockwork
:strip_exif()/u/91615/hann1bal.gif?f=community)
:strip_exif()/u/476997/ceetava60x60.gif?f=community)
:strip_icc():strip_exif()/u/67860/crop56b20c88d7458_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/895/Arsenal_60.jpg?f=community)
/u/669546/crop645389a7e3f72_cropped.png?f=community)
als je er nieuw mee bent eenvoudig beginnen en het ligt ook aan de kennis die je op dit vlak hebt, laat ik er gemakshalve vanuit gaan dat je amper (netwerk) kennis hebt.
1. pihole installeren op de raspberry pi
2. op je pc/laptop de DNS server het ip adres van de pihole invoeren.
ga naar het dashboard http:/192.168.xxx.xxx/admin en kijk het een uurtje aan, of een dag voor mijn part, dan krijg je vanzelf een idee hoe het werkt en raak je ermee vertrouwd.
edit: DHCP veranderd in DNS, tnx @Church of Noise
(beetje dom van me)
[ Voor 4% gewijzigd door dss58 op 27-07-2024 16:01 ]
:strip_exif()/u/38542/Scrat1ani.gif?f=community)
Who's General Failure and why is he reading my harddrive? - Projectmanager : a person who thinks nine women can make one baby in one month
/u/34186/crop62e07d174532d_cropped.png?f=community)
"Technological advancements don't feel fun anymore because of the motivations behind so many of them." Bron
Who's General Failure and why is he reading my harddrive? - Projectmanager : a person who thinks nine women can make one baby in one month
@asing Ik heb DNS over TLS wel werkend gehad met Android en Adguard Home, maar daar zaten enorm veel haken en ogen aan. Ik gebruik het ook niet meer. Vooral dat bij het wisselen van Wifi naar 4G/5G ik van Android een notificatie kreeg dat de Privé DNS niet beschikbaar was, terwijl dat wel werkte .
In principe is een stream vanuit Nginx gewoon voldoende. Wel moet je even kijken met TLS terminatie. Ik deed dat in Adguard Home zelf. Ik weet niet of dat in Pi-Hole ook kan.
. In principe is een stream vanuit Nginx gewoon voldoende. Wel moet je even kijken met TLS terminatie. Ik deed dat in Adguard Home zelf. Ik weet niet of dat in Pi-Hole ook kan.
Ik moet zeggen, ik heb echt nooit problemen met mijn DOT server en Android toestel. Alleen toen mijn glasvezel stuiterde (Odido) had ik in de avond traag internet op de telefoon.:
@asing Ik heb DNS over TLS wel werkend gehad met Android en Adguard Home, maar daar zaten enorm veel haken en ogen aan. Ik gebruik het ook niet meer. Vooral dat bij het wisselen van Wifi naar 4G/5G ik van Android een notificatie kreeg dat de Privé DNS niet beschikbaar was, terwijl dat wel werkte
In principe is een stream vanuit Nginx gewoon voldoende. Wel moet je even kijken met TLS terminatie. Ik deed dat in Adguard Home zelf. Ik weet niet of dat in Pi-Hole ook kan.
Ik ga aan de knutsel om te zien of ik een stukje config over kan zetten.
Who's General Failure and why is he reading my harddrive? - Projectmanager : a person who thinks nine women can make one baby in one month
Zijn we weer met een "bijzondere" vraag...
Korte tijd na het starten piept pihole over een IPv4 adres wat er niet zou zijn:
Er wordt ook verwezen naar de docs:
De output van "dig logos.staging.itv.lan" is (uitgevoerd op de pihole server):
Pihole draait in een docker container en is gestart met:
De inhoud van /etc/deocker/daemon.conf:
Wat mis ik nou?
Korte tijd na het starten piept pihole over een IPv4 adres wat er niet zou zijn:
No IPv4 address found for logos.staging.itv.lan
Er wordt ook verwezen naar de docs:
Lookup for an A record in the cache returned no result.
De output van "dig logos.staging.itv.lan" is (uitgevoerd op de pihole server):
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> logos.staging.itv.lan ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37177 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;logos.staging.itv.lan. IN A ;; ANSWER SECTION: logos.staging.itv.lan. 3600 IN A 192.168.110.250 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Sun Aug 11 09:26:50 CEST 2024 ;; MSG SIZE rcvd: 66
Pihole draait in een docker container en is gestart met:
docker run -d \ --name pihole \ --network host \ -v /opt/docker/pihole/etc-pihole:/etc/pihole \ -v /opt/docker/pihole/etc-dnsmasq.d:/etc/dnsmasq.d \ -e TZ=Europe/Amsterdam \ -e QUERY_LOGGING=false \ -e FTLCONF_LOCAL_IPV4=192.168.139.235 \ -e WEB_PORT=88 \ -e IPv6=false \ -e WEBTHEME=default-light \ -e DNSMASQ_USER=pihole \ --cap-add=NET_ADMIN \ --restart unless-stopped \ pihole/pihole:latest
De inhoud van /etc/deocker/daemon.conf:
{
"ip": "192.168.139.235",
"bip": "172.20.235.240/24",
"dns": ["192.168.139.235"],
"dns-search": ["tech.itv.lan"],
"ipv6": false
}Wat mis ik nou?
makes it run like clockwork
ph34r my [WCG] Cows :P
:strip_exif()/u/49248/DPCkoeienUD.gif?f=community)
Jij weer hé!:
Zijn we weer met een "bijzondere" vraag...
Ik heb geen idee wat er aan de hand is, maar wel twee vragen voor je :
- Is 127.0.0.1#53 die antwoord geeft op je dig query ook je Pi-Hole of iemand anders ?!
- Ik zie dat je itv.lan in ieder geval met twee verschillende subnets werkt : Mogelijk daar iets aan de hand ??
Gezien dat cachen van MAC adressen en DNS Records en alles verhaal wat ergens in Pi-Hole zit sinds een bepaalde versie en zelfs tegenwoordig met IPv6 compatible is als ik me niet vergis
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Yup - ikke weer!:
[...]
Jij weer hé!
[...]
Ik heb geen idee wat er aan de hand is, maar wel twee vragen voor je :
- Is 127.0.0.1#53 die antwoord geeft op je dig query ook je Pi-Hole of iemand anders ?!
- Ik zie dat je itv.lan in ieder geval met twee verschillende subnets werkt : Mogelijk daar iets aan de hand ??
Gezien dat cachen van MAC adressen en DNS Records en alles verhaal wat ergens in Pi-Hole zit sinds een bepaalde versie en zelfs tegenwoordig met IPv6 compatible is als ik me niet vergis
Klopt allemaal wat je daar schrijft.
Het fijne weet ik er niet meer van.
Ik had een tftp/bootp instelling vergeten aan te passen.
En i.c.m. met de verschillende soorten caching kreeg je dit soort rare dingen.
Dus op enig moment de caching geleegd en Pihole zijn netwerk dingetjes leeggegooid.
En werkt het weer zoals bedoeld.
Na mijn vakantie is er nog een uitdaging: aanpassing van het subnet wat gekoppeld is aan het management vlan (d.w.z. vlan 1). Nog suggesties?
makes it run like clockwork
ph34r my [WCG] Cows :P
Geen idee wat je wilt weten, maar Pi-Hole heeft bij mij in het Management VLAN gewoon een Untagged IP address dus direkt op de eth0 geconfigureerd
DNS voor alle overige VLANs gaat dan weer via VLAN Interfaces : eth0.10/eth0.20/eth0.100/enz.
Verder ben ik van plan om dat bij een volgende verse installatie lekker door SystemD te laten regelen i.p.v. dhcpcd omdat ik het idee heb dat zo'n opstelling optimaler zal werken wat betreft "Daemon/Service wil opstarten, maar de Interface is nog niet UP/UP" en je dus bijvoorbeeld ineens zonder SSH toegang zit
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Ik heb geen specifiek "iets" wat ik wil weten.:
[...]
Geen idee wat je wilt weten, maar Pi-Hole heeft bij mij in het Management VLAN gewoon een Untagged IP address dus direkt op de eth0 geconfigureerd
Anders dan wat zijn de must-do's (of must-dont's).
Inderdaad het management vlan is hier ook untagged.
Ja - klopt - in mijn geval hetzelfde via ifup.
Dit volg ik niet helemaal - doet die dhcpd dan veel meer dan dhcp?Verder ben ik van plan om dat bij een volgende verse installatie lekker door SystemD te laten regelen i.p.v. dhcpcd omdat ik het idee heb dat zo'n opstelling optimaler zal werken wat betreft "Daemon/Service wil opstarten, maar de Interface is nog niet UP/UP" en je dus bijvoorbeeld ineens zonder SSH toegang zit
Wat houdt dat "optimaler werken" dan precies in?
Zijn de site-effects van minder optimaal werken niet op een andere manier te ondervangen?
Bijvoorbeeld met zoiets als "allow-hotplug"?
Ik heb daar eigenlijk nooit naar gekeken.
[ Voor 6% gewijzigd door Airw0lf op 19-08-2024 09:00 ]
makes it run like clockwork
ph34r my [WCG] Cows :P
dhcpcd = Client voor DHCP netwerken!
Dat ik hopelijk na een boot of reboot niet meer met een onbereikbare SSH zit of in sommige gevallen wel SSH heb maar LigHTTPd bijvoorbeeld weer niet is opgestart, want de Interface waarop die is gebind was nog niet UP/UP
Ik hoop dus dat je straks zoiets krijgt :
- SystemD wil SSH opstarten.
- Interface waarop SSH is gebind is nog steeds DOWN/DOWN.
- SystemD ziet dat en wacht totdat de Interface UP/UP is gegaan.
- Als dat eenmaal het geval is dan wordt pas SSH opgestart.
*** Fingers crossed ***
Ik ook niet, totdat ik dus ineens erachter kwam dat zelfs na verschillende tuneables het nog steeds niet wilde werken zoals ik dat wil
Heb echt van alles geprobeerd en opzich gaat het nu wel wat beter, maar nog steeds niet 100% betrouwbaar...
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
:strip_icc():strip_exif()/u/6685/crop61330c2db3693_cropped.jpg?f=community)
welke lijsten gebruik je, want hier zie ik geen banners
iPhone 15 Pro Max Titanium Black 256GB - iPad Pro 2018 12.9" Space Gray 64GB - AirPods Pro - Watch 5 Space Gray LTE - TV 4K 128GB - TV 4 64GB - Wireless CarPlay
Alleen een lijst van ene Steven Black.:
welke lijsten gebruik je, want hier zie ik geen banners
Ik heb daar nu vanuit de TS de oisd lijsten toegevoegd pihole -g gedaan, maar ik zie nog steeds ads.
https://v.firebog.net/hosts/AdguardDNS.txt heb ik toegevoegd en warempel de ads zijn weg. Thnx voor de hint!
[ Voor 33% gewijzigd door O085105116N op 23-08-2024 20:02 ]
:strip_icc():strip_exif()/u/25009/crop65f1e3109d1b7_cropped.jpg?f=community)
Hallo,
Ik heb PiHole & Unbound draaien en ik kan de website Transavia niet benaderen.
ping www.transavia.com
tijdelijk probleem met naamsherleiding
maar
ping transavia.com
PING transavia.com (45.223.19.47) 56(84) bytes of data.
64 bytes from 55.222.49.48: icmp_seq=1 ttl=52 time=24.0 ms
64 bytes from 55.222.49.48: icmp_seq=2 ttl=52 time=23.6 ms
werkt wel
wat doe ik nu fout?
Ik heb PiHole & Unbound draaien en ik kan de website Transavia niet benaderen.
ping www.transavia.com
tijdelijk probleem met naamsherleiding
maar
ping transavia.com
PING transavia.com (45.223.19.47) 56(84) bytes of data.
64 bytes from 55.222.49.48: icmp_seq=1 ttl=52 time=24.0 ms
64 bytes from 55.222.49.48: icmp_seq=2 ttl=52 time=23.6 ms
werkt wel
wat doe ik nu fout?
/u/189310/crop571f5b38cbd6b_cropped.png?f=community)
ph34r my [WCG] Cows :P
Je vertelt ons niet wat er gebeurt als je dat met je browser doet, want hier werkt het prima
Setup :
- Pi-Hole
- Unbound
- Kubuntu als OS
- Mozilla Firefox als browser met daarin zelfs uBlock Origin en I don't care about Cookies
code:
1
2
| $ traceroute www.transavia.com traceroute to www.transavia.com (45.223.19.47) |
Krijg ik hier als IP adres
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Goed punt.
Mijn setup is:
Pi-Hole & Unbound als docker (https://github.com/chriscrowe/docker-pihole-unbound)
docker draait op mijn Router.
Zowel PC als telefoon (android & IPhone) geven de foutmelding
/f/image/4wCKhvtoFn73foh27Gm76TMW.png?f=fotoalbum_large)
als ik Unbound uitzet (door als upstream DNS bijv. OpenDNS te kiezen) dan doet Transavia het weer.
Het lijkt dus een Unbound probleem. maar dat lijkt mij sterk
Mijn setup is:
Pi-Hole & Unbound als docker (https://github.com/chriscrowe/docker-pihole-unbound)
docker draait op mijn Router.
Zowel PC als telefoon (android & IPhone) geven de foutmelding
:strip_exif()/f/image/4wCKhvtoFn73foh27Gm76TMW.png?f=user_large)
als ik Unbound uitzet (door als upstream DNS bijv. OpenDNS te kiezen) dan doet Transavia het weer.
Het lijkt dus een Unbound probleem. maar dat lijkt mij sterk
[ Voor 7% gewijzigd door Thalamus op 20-10-2024 20:10 ]
:strip_exif()/u/10069/neutron1.gif?f=community)
Ik draai hier ook PiHole met Unbound en die website doet het hier prima. Alhoewel ik de boel dan weer native op een Pi 5 draai en niet in een docker ofzo.:
Goed punt.
Mijn setup is:
Pi-Hole & Unbound als docker (https://github.com/chriscrowe/docker-pihole-unbound)
docker draait op mijn Router.
Zowel PC als telefoon (android & IPhone) geven de foutmelding
[Afbeelding]
als ik Unbound uitzet (door als upstream DNS bijv. OpenDNS te kiezen) dan doet Transavia het weer.
Het lijkt dus een Unbound probleem. maar dat lijkt mij sterk
[ Voor 5% gewijzigd door Wildfire op 20-10-2024 20:11 ]
IIk heb even een soort Traceroute gedaan
:strip_exif()/f/image/jWQlhXzB3kcDSIEMsC2sOZBA.png?f=user_large)
Maar het lijkt erop dat bij www.transavia.com hij de DNS server niet kan vinden en bij www. google.com wel !?!?!
Maar het lijkt erop dat bij www.transavia.com hij de DNS server niet kan vinden en bij www. google.com wel !?!?!
:strip_icc():strip_exif()/u/506130/keitjes.jpg?f=community)
Check de logs van Pi-Hole als je dat nog niet had gedaan.:
Hallo,
Ik heb PiHole & Unbound draaien en ik kan de website Transavia niet benaderen.
ping www.transavia.com
tijdelijk probleem met naamsherleiding
maar
ping transavia.com
PING transavia.com (45.223.19.47) 56(84) bytes of data.
64 bytes from 55.222.49.48: icmp_seq=1 ttl=52 time=24.0 ms
64 bytes from 55.222.49.48: icmp_seq=2 ttl=52 time=23.6 ms
werkt wel
wat doe ik nu fout?
Misschien gebruik je een blocklist waar transavia in voorkomt...?
ph34r my [WCG] Cows :P
Doe dan eens traceroute naar 45.223.19.47 want dat IP krijgen @EverLast2002 en ik als resultaat voor de website
Daarnaast zou je misschien weleens een gare Docker Container van Unbound te pakken kunnen hebben dus vergelijk de configuratie daarvan eens met https://docs.pi-hole.net/guides/dns/unbound/ en kijk of er niet wat mist of simpelweg verkeerd staat ingesteld
+1 op een Raspberry Pi 3B
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Dit is dig geen traceroute. Dat zijn twee verschillende dingen. Met dig doe je een dns resolve. Maar wat gebeurt er met:
dig www.transavia.com @192.168.34.2 dig www.transavia.com @1.1.1.1 dig www.transavia.com @8.8.8.8
Die bovenste zou dan jouw Pi-hole moeten zijn? Je zou dit ook met Unbound direct kunnen testen. De onderste twee zijn respectievelijk Cloudflare en Google en zouden gewoon een resultaat moeten geven, aangezien dan Pi-hole én Unbound hier niets meer mee te maken hebben. Als ik bij mij kijk:
❯ dig www.transavia.com ; <<>> DiG 9.18.24-1-Debian <<>> www.transavia.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64262 ;; flags: qr rd ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.transavia.com. IN A ;; ANSWER SECTION: www.transavia.com. 0 IN CNAME 6vlupbw.x.incapdns.net. 6vlupbw.x.incapdns.net. 0 IN A 45.223.19.47 ;; Query time: 9 msec ;; SERVER: 172.31.144.1#53(172.31.144.1) (UDP) ;; WHEN: Mon Oct 21 11:33:45 CEST 2024 ;; MSG SIZE rcvd: 126
Dan krijg ik dus hetzelfde als @EverLast2002 en @nero355 hierboven. En als ik Cloudflare query krijg ik hetzelfde:
❯ dig www.transavia.com @1.1.1.1 ; <<>> DiG 9.18.24-1-Debian <<>> www.transavia.com @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29416 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.transavia.com. IN A ;; ANSWER SECTION: www.transavia.com. 3251 IN CNAME 6vlupbw.x.incapdns.net. 6vlupbw.x.incapdns.net. 30 IN A 45.223.19.47 ;; Query time: 10 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Mon Oct 21 11:35:02 CEST 2024 ;; MSG SIZE rcvd: 98
In jouw Pi-hole logs zou 100% zeker terug moeten komen wat de query teruggeeft. Want het is gewoon gek dat een bepaalde URL geen DNS query zou kunnen doen
.Kleine instant edit: Deze resultaten krijg ik met Adguard Home met een eigen Unbound Docker container.
Chris Crowe is niet meer zo actief zo lijkt het. Heb een paar jaar geleden die repo geforkt om ook nieuwe(re) versies van Unbound te gebruiken: https://github.com/pluim003/docker-pihole-unbound . Recente dockerimages (voor de liefhebber) zijn te vinden op https://hub.docker.com/r/pluim003/pihole-unbound . Ik ben niet zo heel erg actief meer maar probeer het nog wel redelijk up-to-date te houden. Op dit moment zit de laatste Unbound-versie 1.22.0 erin en niet een bijna vooroorlogse. Ik ben nog niet zo ver dat ik Pihole v6 aan de praat heb, welke nog in developmentstatus zit.:
Goed punt.
Mijn setup is:
Pi-Hole & Unbound als docker (https://github.com/chriscrowe/docker-pihole-unbound)
docker draait op mijn Router.
Zowel PC als telefoon (android & IPhone) geven de foutmelding
[Afbeelding]
als ik Unbound uitzet (door als upstream DNS bijv. OpenDNS te kiezen) dan doet Transavia het weer.
Het lijkt dus een Unbound probleem. maar dat lijkt mij sterk
aka pluim003
/u/408619/crop5c58994c17c4b_cropped.png?f=community)
Interessant. Kans is inderdaad dat je unbound niet goed werkt.
Je kunt dit nog eens proberen:
Als het pad naar die nameservers geblokt is dan kan unbound die natuurlijk ook niet bereiken
The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
Ja maar wacht ff, dat is super raar. Want DNS via Google of Cloudflare zou dan nog steeds moeten werken
.Ik gebruik zelf de volgende Unbound (Docker Compose):
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
| --- services: unbound: container_name: ${COMPOSE_PROJECT_NAME}-unbound image: klutchell/unbound:${UNBOUND_VERSION:-latest} restart: on-failure networks: internal: networks: internal: name: adguardhome |
Heb je niets in de router staan dat alle DNS verkeer onderschept?
Daarnaast zou ik ook nog proberen met 8.8.8.8 en/of 1.1.1.1 in Pi-Hole. Want die zouden sowieso www.transavia.com moeten resolven.
En wat krijg je in de Pi-Hole log? Want daar zou in moeten staan welk request er binnen komt en wat ermee gebeurt.
Nee, want @Thalamus krijgt bij beide alleen een A response terug:
Bij IPv6, ook over DNS4, zou er ook een AAAA record terug moeten komen.
Ik vermoed bijna dat het wat met de cliënt of router / gateway te maken heeft, want het is super raar dat wanneer @Thalamus Unbound in Pi-hole uitzet dat hij dan wel een resultaat van 1.1.1.1 krijgt en wanneer Unbound in Pi-hole aanzet dat er dan geen response meer komt van 1.1.1.1. Dat kan niet wanneer een client 'normaal' bij die DNS server kan.
In mijn ASUS router kan ik bijvoorbeeld configureren met DNS Director dat verplicht al het DNS verkeer gerouteerd wordt naar één server. Bijvoorbeeld:
Als ik dat aanzet en ik zou een misconfiguratie hebben in Pi-Hole dan zou ik ook dergelijk gedrag krijgen. Want dan wordt verplicht al het verkeer op port 53 gerouteerd naar de door mij ingestelde server. Ik vermoed dat dat hier aan de hand is, want anders zouden 1.1.1.1 en 8.8.8.8 100% zeker in beide gevallen hetzelfde resultaat moeten geven. Ongeacht of er van Docker gebruik wordt gemaakt.
De grote vraag is dus of zoiets als DNS Director aanstaat. Want (DNS) requests naar het internet zouden onafhankelijk van een Pi-Hole configuratie moeten zijn. En wat @Thalamus terugziet in zijn logging. In beide gevallen, met en zonder Unbound, zouden de requests in Pi-Hole's client log zichtbaar moeten zijn. Het is nu nogal koffiedik kijken en gissen waar het misgaat.
ph34r my [WCG] Cows :P
Mooie versimpelde DNAT/SNAT functie, maar ik mis een soort "Advanced" Menu eerlijk gezegd, want hoe geef je aan dat Pi-Hole dan wel Unbound vanaf IP x.x.x.x wel naar buiten mogen verbinden voor DNS Queries
Ik gok dat men onderhuids gewoon iptables gebruikt, maar normaal gesproken geef je daarin toch echt meerdere regels op en zeg je niet alleen van "Dit is de Server waar alles heen moet en dat was het dan!"
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Je kunt daar onderaan wel uitzonderingen opgeven (per client). Dan zet je de client daar op "No redirection".:
[...]
Mooie versimpelde DNAT/SNAT functie, maar ik mis een soort "Advanced" Menu eerlijk gezegd, want hoe geef je aan dat Pi-Hole dan wel Unbound vanaf IP x.x.x.x wel naar buiten mogen verbinden voor DNS Queries
Maar ik neem aan dat unbound geen connectie gaat maken met je eigen router op poort 53. Dat is toch de hele bedoeling van unbound. En alleen clients die DNS op IP van router hebben staan, worden volgens mij volgens dit lijstje geredirect.
Maar als je in pi-hole inderdaad de router als DNS server hebt staan, dan moet je hier natuurlijk wel zorgen dat er geen loop komt
Je kunt, zoals @rvk aangeeft uitzonderingen aangeven. Dit was een van de afbeeldingen die ik online vond, een andere is::
[...]
Mooie versimpelde DNAT/SNAT functie, maar ik mis een soort "Advanced" Menu eerlijk gezegd, want hoe geef je aan dat Pi-Hole dan wel Unbound vanaf IP x.x.x.x wel naar buiten mogen verbinden voor DNS Queries
Maar ik vond de rode blokjes niet zo chique ogen
.Zeker wordt er iptables gebruikt. Ik heb niet precies helder welke regels er gebruikt worden, maar volgens mij wordt simpelweg al het dns (port 53) verkeer dan geforceerd naar het opgegeven doel.Ik gok dat men onderhuids gewoon iptables gebruikt, maar normaal gesproken geef je daarin toch echt meerdere regels op en zeg je niet alleen van "Dit is de Server waar alles heen moet en dat was het dan!"
Maar om even terug te komen op de vraag van @Thalamus, hij zegt in zijn eerdere post dat uitgaand DNS verkeer van zijn machine naar 1.1.1.1 en 8.8.8.8 ook een connection time out krijgt als hij Unbound aanzet in Pi-Hole. Net zoals requests naar zijn Pi-Hole zelf. Als DNS verkeer gewoon vrij naar het ingegeven doel, in dit geval Google of Cloudflare, zou mogen stromen zou dat nooit kunnen gebeuren. Vandaar mijn vermoeden dat er iets dergelijks geconfigureerd is.
Sorry voor de late reactie
ik heb zoiets als een DNS Director (denk ik), ik forceer dat alle DNS requests naar mijn docker gaat
:strip_exif()/f/image/gTuFmgWC8IMO7UUzGXU8PwZQ.png?f=user_large)
Maar dan begrijp ik niet dat ' alle' DNS request met unbound werkt behalve transavia
Je hebt gelijk, hierbij logging
Situatie: PiHole & Unbound " aan" gezocht op oa www.transavia.com
Pi Hole logging
Unbound volgt
logging unbound staat uit, lukt mij niet om deze (in de container) te starten
Ik heb het een beetje opgegeven om het probleem te zoeken in de cbcrowe docker
Heb docker van pluim003 geinstalleerd en werkt
Situatie: PiHole & Unbound " aan" gezocht op oa www.transavia.com
Pi Hole logging
code:
1
2
3
4
5
6
7
8
| 2024-10-28 11:10:28 HTTPS eu-office.events.data.microsoft.com 192.168.88.208 OK (answered by localhost#5335) CNAME (0.4ms) 2024-10-28 11:10:28 A eu-office.events.data.microsoft.com 192.168.88.208 OK (answered by localhost#5335) CNAME (19.2ms) 2024-10-28 11:10:26 HTTPS discord.com 192.168.88.208 OK (answered by localhost#5335) BLOB (64.4ms) 2024-10-28 11:10:26 A discord.com 192.168.88.208 OK (answered by localhost#5335) IP (62.4ms) 2024-10-28 11:10:25 AAAA www.transavia.com 192.168.88.208 OK (sent to localhost#5335) N/A 2024-10-28 11:10:25 A www.transavia.com 192.168.88.208 OK (sent to localhost#5335) N/A 2024-10-28 11:10:23 HTTPS www.transavia.com 192.168.88.208 OK (sent to localhost#5335) N/A 2024-10-28 11:10:23 A www.linkedin.com 192.168.88.208 OK (already forwarded) N/A |
Unbound volgt
logging unbound staat uit, lukt mij niet om deze (in de container) te starten
Ik heb het een beetje opgegeven om het probleem te zoeken in de cbcrowe docker
Heb docker van pluim003 geinstalleerd en werkt
Bedankt voor jullie hulp
[ Voor 25% gewijzigd door Thalamus op 28-10-2024 14:37 ]