Pi-Hole - mainosblokkeri raspberry pi:stä

On hölmöä kyllä jos se on automaattisesti ubuntussa päällä ja jokainen voi ottaa siihen ssh yhteyden halutessaan mistä vain ?
No se edellyttää suurempaa hölmöyttä, eli kytkee sen suoraan internetiin ilman palomuuria, vähintään vaihtamatta sshd-autentikointimenetelmäksi sertifikaattia salasanan tilalle ja tutkimatta muita avoimia portteja
EDIT: Ja todennäköisesti Ubuntun työpöytäversiossa ssh-serveriä ei oletuksena ole muutenkaan
 
No se edellyttää suurempaa hölmöyttä, eli kytkee sen suoraan internetiin ilman palomuuria, vähintään vaihtamatta sshd-autentikointimenetelmäksi sertifikaattia salasanan tilalle ja tutkimatta muita avoimia portteja
Niin joo tietysti, en huomioinu tuota ollenkaan.
 
Pariin kertaan tuoreiden pihole-versiopäivitysten jälkeen (ehkä alkaen v5.2.3:sta) blokkaus on pudonnut päältä ja pitänyt startata uudelleen:
[root@pihole pihole]# pihole enable
 
Viimeksi muokattu:
Siltä varalta, että joku ei ole huomannut tätä lupaavaa opensource -hallinta-aplaria Androidiin: FlutterHole for Pi-Hole® - Apps on Google Play
EDIT: Jos tai kun alussa näet virhepop-upin kun aplaria ei ole vielä liitetty piholeen, paina back niin se häviää. Tästä oli joku valittanut Store-arvostelussakin
 
Viimeksi muokattu:
Onko PiHolelle hyviä blokkilistoja? Meinaa mukana tulleen listan läpi tulla kaikki mainokset.
 
Onko PiHolelle hyviä blokkilistoja? Meinaa mukana tulleen listan läpi tulla kaikki mainokset.

Minulla on mm tämmöiset käytössä:
Koodi:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
https://raw.githubusercontent.com/harriko/suomimainostajat/master/hosts

Steven Blackillä on myös "lisäosia" tuohon Master listiin.
 
Onko PiHolelle hyviä blokkilistoja? Meinaa mukana tulleen listan läpi tulla kaikki mainokset.
Kannattaa varmistaa ettei clientin omat DNS-asetukset ohita sun PiHolea.

Vähän riippuu kanssa mitä haluat blokata.... Teen töitä Win koneilla, niin tykkään tästä

Lasten vuoksi on myös pornolista
https://raw.githubusercontent.com/c...lists/master/lists/pi_blocklist_porn_all.list
Itse käyttäisin jonkun julkisen DNS-palvelun (Cloudflare, NextDNS, OpenDNS) pornon estoja, yksittäisen listan sijasta. Lipsumisia voi tapahtua kenelle vain, joten DNS:n kanssa päivittäin painivat ylläpitäjät ovat ainakin teoriassa astetta varmempia kuin yksittäinen ylläpitäjä. Esim. NextDNS:lla voi oikeastaan korvata koko PiHolen, ellei sen ylläpitäminen kuulu lempiharrastuksiin. :)
 
Kokeilin parin kuukauden tauon jälkeen Ruutu Android appia ja huomasin, että oma pihole ei enää osannut blokata mainoksia. Aiemmin blokkasi ihan nätisti. Onko muilla samoja huomioita? Laitteena Nvidian Shield tv.
 
Saako piholen jotenkin käyttämään Nextdns palvelua siten että pääsee myös säätämään tuota konfiguraatiota kun nyt jos kokeilen laittaa dns osoitteet piholeen niin nextdns konf sivu sanoo tietenkin näin :

This device is using NextDNS with no configuration.
Make sure to link your IP address in the Linked IP section below

Mutta onko tuo mitenkään mahdollista päästä itse säätäämään syvemmin asetuksia ja kokeilemaan riittääkö tuo ilmainen 300k.
 
kun nyt jos kokeilen laittaa dns osoitteet piholeen niin nextdns konf sivu sanoo tietenkin näin :
Varmaan NextDNS-ketjussa (DNS-palvelut) olisi parempi kysyä. Ilmeisesti NDNS:ään pitää tehdä jonkinlainen käyttäjätunnus ja piholeen sitten konffata ainoaksi DNS-palvelimeksi NextDNS
EDIT: NextDNS
 
Saako piholen jotenkin käyttämään Nextdns palvelua siten että pääsee myös säätämään tuota konfiguraatiota kun nyt jos kokeilen laittaa dns osoitteet piholeen niin nextdns konf sivu sanoo tietenkin näin :

This device is using NextDNS with no configuration.
Make sure to link your IP address in the Linked IP section below

Mutta onko tuo mitenkään mahdollista päästä itse säätäämään syvemmin asetuksia ja kokeilemaan riittääkö tuo ilmainen 300k.

Tee tunnus, linkitä profiili julkisella ipllä, ajasta esim. piholen kone cronilla ajaamaan wget "profiilin url" > /dev/null. Sitten pysyy kohdallaan, vaikka julkinen ip vaihtuu.
 
Varmaan NextDNS-ketjussa (DNS-palvelut) olisi parempi kysyä. Ilmeisesti NDNS:ään pitää tehdä jonkinlainen käyttäjätunnus ja piholeen sitten konffata ainoaksi DNS-palvelimeksi NextDNS
EDIT: NextDNS

Joo, ajattelin sen liittyvän vain enemmän piholeen ja sen säätöihin kun itse dns ketjuun.

Tee tunnus, linkitä profiili julkisella ipllä, ajasta esim. piholen kone cronilla ajaamaan wget "profiilin url" > /dev/null. Sitten pysyy kohdallaan, vaikka julkinen ip vaihtuu.
Tuo ei luullakseni ihan ollut sitä mitä hain, mutta kiitos silti.


Spämmään tähän vielä mitä sain aikaiseksi tutkittua. Koska en ole nyt enää ollenkaan varma haluanko edes konffattavaa itselleni lisää.

Mutta löysin ohjeen jonka mukaan olisi kyllä joo tehtävä se tili (NextDNS). Ja kun tili olisi tehty niin se olisi muotoa tyyliiä my.nextdns.io/12345. Sitten siihen piholea pyörittävään laitteeseen olisi asennettava stubby ohjelma (Dns Over TLS). Kun stubbyn on konffannu oikein, stubbyn asetuksiin lisätään vielä se NextDNS configuration osoite joka on sitten tyyliä tämä (Dns Over Tls) 12345.dns.nextdns.io

Eli stubbyn konffausta
round_robin_upstreams: 0
upstream_recursive_servers:
- address_data: 45.90.28.0
tls_auth_name: "12345.dns1.nextdns.io"
- address_data: 2a07:a8c0::0
tls_auth_name: "12345.dns1.nextdns.io"

+ jotain muuta pientä konffia stubbyyn mm. listen address ja portit.

Viimeisenä sitten vain lisäillä piholen dns asetuksiin 127.0.0.1#5353 <- portti sama mikä stubbyn konfiguraation sitten ikinä onkaan määritettynä.

Joskus aiemmin kun tutkin miten piholeen saisi pelkän DoT:in toimimaan, tämä oli juuri hyvin samankaltainen ohje mitä en saanut itse ensimmäisellä kerralla toimimaan ollenkaan vaikka miten yritti. Tässä alkaa pikkuhiljaa kertymään taas motivaatiota uuten yritykseen, mutta se sitten joskus kun jaksaa.

Mutta tuolla tavalla ilmeisesti saisi NextDNS konfiguraation toimimaan piholen kanssa...Stubby on aika helppo konffata linuxiin yhdelle koneelle toimivaksi, mutta tuossa piholessa en nyt muista mikä tuli vastaan kun en saanut toimimaan.

Edit: Hukkasin ohjeen jo niin tuo on hieman sinne suuntaan vain.
 
Viimeksi muokattu:
Saako piholen jotenkin käyttämään Nextdns palvelua siten että pääsee myös säätämään tuota konfiguraatiota kun nyt jos kokeilen laittaa dns osoitteet piholeen niin nextdns konf sivu sanoo tietenkin näin :

This device is using NextDNS with no configuration.
Make sure to link your IP address in the Linked IP section below

Mutta onko tuo mitenkään mahdollista päästä itse säätäämään syvemmin asetuksia ja kokeilemaan riittääkö tuo ilmainen 300k.
Henkilökohtaisesti en näe tuossa yhdistelmässä minkälaista hyötyä. Miksi siis käyttää kahta päällekkäistä DNS-suodatinta, jossa molemmat nojaavat aika pitkälti samoihin sääntöihin?
 
Henkilökohtaisesti en näe tuossa yhdistelmässä minkälaista hyötyä. Miksi siis käyttää kahta päällekkäistä DNS-suodatinta, jossa molemmat nojaavat aika pitkälti samoihin sääntöihin?

Niin kyllähän se noinkin tietysti on. Ja enemmän vain selvitettäviä paikkoja kun ongelmia tulee vastaan= on lisää työtä.

Mutta ei kai ne varsinaisesti käytä kahta päällekkäistä kun piholeen pitää jokatapauksessa lisätä dns osoitteet mitä haluat käyttää. Näistä muista paitsi Nextdns et pääse konffaamaan yhtään mitään ja se mitä taas pääset tuolla Nextdns konffilla tekemään niin ei piholella ainakaan helpolla tehdä ?

Yksi olisi juurikin tuo että kaikki piholea käyttävät laitteet saisivat DoT:in. Ja nextdns sivulta näkee tarkasti seurata että kaikki kyselyt menee DoT:ina.

Eihän noita kaikkia ominaisuuksia tietenkään pakko olis käyttää mutta on siellä helppo vaan klikkailla päälle mm. tämmöisiä vaihtoehtoja :

Block Parked Domains
Block Child Sexual Abuse Material
Block Newly Registered Domains (NRDs)
Typosquatting Protection


Nuo saa vain klikkailla päälle. Sitten tietenkin on estolistoja runsaasti valittavissa.
Block Disguised Third-Party Trackers
Block Bypass Methods

yms yms.

Sitten on perinteiset black & whitelistit sekä jollain tapaa tykkäsin tuosta analytiikka ja logi sivujen kattavuudesta sekä asetuksista. Nuohan olis vähän semmoisia konffaa & unohda asetuksia piholen lisäksi.

Olis kiva tietää jos laittaa cloudflarea tai ihan mitä muuta vain dns osoitteita piholeen niin onko muissakin palveluissa yhtä kattavia asetuksia mitä käyttäjä ei vain näe missään vaiheessa. Toki sen DoT:in voi toteuttaa jollain muullakin dns palvelulla eikä tuo ilmainen 300k riittäisi mihinkään jos laittaisin sen piholeen pyörimään eli joutuisi maksamaankin palvelusta, mutta en näe sitä niin pahan hintaisena ja ainakaan vielä ei mitään negatiivistä uutisointiakaan ei ole tainnut näkyä Nextdns palvelusta ?
 
Niin kyllähän se noinkin tietysti on. Ja enemmän vain selvitettäviä paikkoja kun ongelmia tulee vastaan= on lisää työtä.

Mutta ei kai ne varsinaisesti käytä kahta päällekkäistä kun piholeen pitää jokatapauksessa lisätä dns osoitteet mitä haluat käyttää. Näistä muista paitsi Nextdns et pääse konffaamaan yhtään mitään ja se mitä taas pääset tuolla Nextdns konffilla tekemään niin ei piholella ainakaan helpolla tehdä ?
On niitä muitakin (Cloudflare, OpenDNS, DNSFilter jne) joissa voi säätää sääntöjä. NextDNS:n säätömahdollisuudet ovat ehdottomasti parhaimmistoa. Cloudflaressa ei voi esim estää mainoksia.

Mitä tulee PiHoleen, NextDNS on käytännössä julkinen PiHole muutamalla eri lisäominaisuudella. PiHole voi olla hyvä jos tykkää purkin ylläpitämisestä, eikä ole valmis maksamaan esim. NextDNS:n hintaa. NextDNS:n etu on se ettei se vaadi mitään VPN-kikkailuja sisäverkon ulkopuolella, toisin kuin Pihole. (Tein NextDNS:stä esittelyvideon, joka löytyy signun linkin takaa.)
 
On niitä muitakin (Cloudflare, OpenDNS, DNSFilter jne) joissa voi säätää sääntöjä. NextDNS:n säätömahdollisuudet ovat ehdottomasti parhaimmistoa. Cloudflaressa ei voi esim estää mainoksia.

Mitä tulee PiHoleen, NextDNS on käytännössä julkinen PiHole muutamalla eri lisäominaisuudella. PiHole voi olla hyvä jos tykkää purkin ylläpitämisestä, eikä ole valmis maksamaan esim. NextDNS:n hintaa. NextDNS:n etu on se ettei se vaadi mitään VPN-kikkailuja sisäverkon ulkopuolella, toisin kuin Pihole. (Tein NextDNS:stä esittelyvideon, joka löytyy signun linkin takaa.)
Hyvä video! Täytyy kokeilla tuota palvelua
 
Hukkasin ohjeen jo niin tuo on hieman sinne suuntaan vain
Tein about noin, Piholeen lisäksi NextDNS käyttäen stubbyä, jossa DNS-over-TLS ja DNSSEC, IPv4v6.
Alun perin pihole käytti pelkkää DnsCryptiä.
EDIT: Vielä helpommin NextDNS:n olisi voinut lisätä DnsCryptiin, mutta koska siellä on iso pooli servereitä oletuksena, niin vain murto-osa queryistä olisi tipahtanut NextDNS:ään. Nyt sinne menee puolet. Koska tässä setupissa on pari containeria: 1=pihole+stubby 2=dnscrypt, niin tuo tekee myös piholen riippumattomaksi kontista 2.
 
Viimeksi muokattu:
Tein about noin, Piholeen lisäksi NextDNS käyttäen stubbyä, jossa DNS-over-TLS ja DNSSEC, IPv4v6.
Alun perin pihole käytti pelkkää DnsCryptiä.
EDIT: Vielä helpommin NextDNS:n olisi voinut lisätä DnsCryptiin, mutta koska siellä on iso pooli servereitä oletuksena, niin vain murto-osa queryistä olisi tipahtanut NextDNS:ään. Nyt sinne menee puolet. Koska tässä setupissa on pari containeria: 1=pihole+stubby 2=dnscrypt, niin tuo tekee myös piholen riippumattomaksi kontista 2.
Minäpä koitan kanssa uudemman kerran tässä lähipäivinä jos saisin sen DoT toimimaan kanssa ! Houkuttaa sen verran nuo muutamat ominaisuudet tuolla nextdns palvelussa.
 
Minäpä koitan kanssa uudemman kerran tässä lähipäivinä jos saisin sen DoT toimimaan kanssa
Omat /etc/stubby/stubby.yml muutokset, kun stubby on lokaalisti piholessa:
Koodi:
# Stubby 0.3.0

< round_robin_upstreams: 1
<
<-listen_addresses:
<   - 127.0.0.1
<   - 0::1
---
> round_robin_upstreams: 0
>
>-listen_addresses:
>   - 127.0.0.1@153
>   - 0::1@153
>
> dnssec: GETDNS_EXTENSION_TRUE
>
> appdata_dir: "/var/cache/stubby"
>
upstream_recursive_servers:
> # NextDMS Stubby guide:
>   - address_data: 45.90.28.0
>     tls_auth_name: "123456.dns1.nextdns.io"
>   - address_data: 2a07:a8c0::0
>     tls_auth_name: "123456.dns1.nextdns.io"
>   - address_data: 45.90.30.0
>     tls_auth_name: "123456.dns2.nextdns.io"
>   - address_data: 2a07:a8c1::0
>     tls_auth_name: "123456.dns2.nextdns.io"
>
> # comment out rest of resolvers
Sitten piholeen IPv4 DNS-asetuksiin 127.0.0.1#153

round_robin_upstreams: 0 on erityisen tärkeä muutos, koska muuten NextDNS:ään tulee jäätävä viive
stubby -i:llä voi tarkistaa, että konffi on kunnossa, tosin se ei ole kovin luotettava
[16:25:34.892295] STUBBY: Stubby version: Stubby 0.3.0
Could not parse config file ###
...
, "Generic error"
Error parsing config file "/etc/stubby/stubby.yml": Generic error
WARNING: No Stubby config file found... using minimal default config (Opportunistic Usage)
Siksi kannattaa aluksi käynnistää stubby foregroundille:
stubby -v 3
[17:10:38.760220] STUBBY: Stubby version: Stubby 0.3.0
[17:10:38.762524] STUBBY: Read config from file /etc/stubby/stubby.yml
[17:10:38.762696] STUBBY: DNSSEC Validation is ON
[17:10:38.762707] STUBBY: Transport list is:
[17:10:38.762766] STUBBY: - TLS
[17:10:38.762770] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[17:10:38.762773] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[17:10:38.762776] STUBBY: Starting DAEMON....
ja testata toisessa terminaalissa, että se toimii:
dig @127.0.0.1 -p 153 bing.com
Lopuksi systemctl enable stubby; systemctl restart stubby (jos on systemd käytössä)
Jos stubby on vaikka stopattuna ja se on jo piholessa käytössä (eikä vastaa), niin pihole ei heti ala käyttää stubbyä uudelleen. Siihen auttaa, kun piholen DNS-asetukset tallentaa ilman muutoksia.
 
Viimeksi muokattu:
Omat /etc/stubby/stubby.yml muutokset, kun stubby on lokaalisti piholessa:
Koodi:
# Stubby 0.3.0

< round_robin_upstreams: 1
<
<-listen_addresses:
<   - 127.0.0.1
<   - 0::1
---
> round_robin_upstreams: 0
>
>-listen_addresses:
>   - 127.0.0.1@153
>   - 0::1@153
>
> dnssec: GETDNS_EXTENSION_TRUE
>
> appdata_dir: "/var/cache/stubby"
>
upstream_recursive_servers:
> # NextDMS Stubby guide:
>   - address_data: 45.90.28.0
>     tls_auth_name: "123456.dns1.nextdns.io"
>   - address_data: 2a07:a8c0::0
>     tls_auth_name: "123456.dns1.nextdns.io"
>   - address_data: 45.90.30.0
>     tls_auth_name: "123456.dns2.nextdns.io"
>   - address_data: 2a07:a8c1::0
>     tls_auth_name: "123456.dns2.nextdns.io"
>
> # comment out rest of resolvers
Sitten piholeen IPv4 DNS-asetuksiin 127.0.0.1#153

round_robin_upstreams: 0 on erityisen tärkeä muutos, koska muuten NextDNS:ään tulee jäätävä viive
stubby -i:llä voi tarkistaa, että konffi on kunnossa, tosin se ei ole kovin luotettava
[16:25:34.892295] STUBBY: Stubby version: Stubby 0.3.0
Could not parse config file ###
...
, "Generic error"
Error parsing config file "/etc/stubby/stubby.yml": Generic error
WARNING: No Stubby config file found... using minimal default config (Opportunistic Usage)
Siksi kannattaa aluksi käynnistää stubby foregroundille:
stubby -v 3
[17:10:38.760220] STUBBY: Stubby version: Stubby 0.3.0
[17:10:38.762524] STUBBY: Read config from file /etc/stubby/stubby.yml
[17:10:38.762696] STUBBY: DNSSEC Validation is ON
[17:10:38.762707] STUBBY: Transport list is:
[17:10:38.762766] STUBBY: - TLS
[17:10:38.762770] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[17:10:38.762773] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[17:10:38.762776] STUBBY: Starting DAEMON....
ja testata toisessa terminaalissa, että se toimii:
dig @127.0.0.1 -p 153 bing.com
Lopuksi systemctl enable stubby; systemctl restart stubby (jos on systemd käytössä)
Jos stubby on vaikka stopattuna ja se on jo piholessa käytössä (eikä vastaa), niin pihole ei heti ala käyttää stubbyä uudelleen. Siihen auttaa, kun piholen DNS-asetukset tallentaa ilman muutoksia.
Taidan tänään kokeilla uudemman kerran tätä. Ihan loistava ! Jos saa toimimaan niin vois maksaakkin tuon 20e nextdns palvelusta ettei se jossain vaiheessa sitten muutu vahingossakaan tai yllätyksenä "non blocking classic" palveluksi...

Hmm. Mulla on LMDE Mint läppärissä vai mikä se versio oli mistä ubuntu on jätetty pois ja on vain debian. No jokatapaussa siinä Mint läppärissä pyörii pihole. Pitääköhän sen läppärin verkkoasetuksiin muuttaa kans jotain ? Vai riittääköhän että nuo listen address on stubbyn konffissa sekä piholen dns sivulla ?

Edit : Ei tietenkeen läppärin verkkoasetuksia varmastikkaan tarvitse muuttaa koska nehän on taas sieltä tiedot edgerouterissa että edgerouter tietää miten toimia tuon läppärin kanssa mjoo niin se taitaa ollakki.
 
Viimeksi muokattu:
Omat /etc/stubby/stubby.yml muutokset, kun stubby on lokaalisti piholessa:
Koodi:
# Stubby 0.3.0

< round_robin_upstreams: 1
<
<-listen_addresses:
<   - 127.0.0.1
<   - 0::1
---
> round_robin_upstreams: 0
>
>-listen_addresses:
>   - 127.0.0.1@153
>   - 0::1@153
>
> dnssec: GETDNS_EXTENSION_TRUE
>
> appdata_dir: "/var/cache/stubby"
>
upstream_recursive_servers:
> # NextDMS Stubby guide:
>   - address_data: 45.90.28.0
>     tls_auth_name: "123456.dns1.nextdns.io"
>   - address_data: 2a07:a8c0::0
>     tls_auth_name: "123456.dns1.nextdns.io"
>   - address_data: 45.90.30.0
>     tls_auth_name: "123456.dns2.nextdns.io"
>   - address_data: 2a07:a8c1::0
>     tls_auth_name: "123456.dns2.nextdns.io"
>
> # comment out rest of resolvers
Sitten piholeen IPv4 DNS-asetuksiin 127.0.0.1#153

round_robin_upstreams: 0 on erityisen tärkeä muutos, koska muuten NextDNS:ään tulee jäätävä viive
stubby -i:llä voi tarkistaa, että konffi on kunnossa, tosin se ei ole kovin luotettava
[16:25:34.892295] STUBBY: Stubby version: Stubby 0.3.0
Could not parse config file ###
...
, "Generic error"
Error parsing config file "/etc/stubby/stubby.yml": Generic error
WARNING: No Stubby config file found... using minimal default config (Opportunistic Usage)
Siksi kannattaa aluksi käynnistää stubby foregroundille:
stubby -v 3
[17:10:38.760220] STUBBY: Stubby version: Stubby 0.3.0
[17:10:38.762524] STUBBY: Read config from file /etc/stubby/stubby.yml
[17:10:38.762696] STUBBY: DNSSEC Validation is ON
[17:10:38.762707] STUBBY: Transport list is:
[17:10:38.762766] STUBBY: - TLS
[17:10:38.762770] STUBBY: Privacy Usage Profile is Strict (Authentication required)
[17:10:38.762773] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!)
[17:10:38.762776] STUBBY: Starting DAEMON....
ja testata toisessa terminaalissa, että se toimii:
dig @127.0.0.1 -p 153 bing.com
Lopuksi systemctl enable stubby; systemctl restart stubby (jos on systemd käytössä)
Jos stubby on vaikka stopattuna ja se on jo piholessa käytössä (eikä vastaa), niin pihole ei heti ala käyttää stubbyä uudelleen. Siihen auttaa, kun piholen DNS-asetukset tallentaa ilman muutoksia.
@mikajh

Kävi niinkuin viimeksikin. Ei tuolla sinunkaan laittamallasi ohjeella lähde netti toimimaan.

Tässä hieman error ilmoituksia mitä tulee sieltä täältä.

dig @127.0.0.1 -p 153 bing.com
Connection timed out; no servers could be reached

Stubbyn konffin tarkistus komento aloittaa errorilla
Parse error : while parsing a block mapping at line 36 column1
did not find expected key at line 130 column 3 (otin tämän pois käytöstä, ei vaikutusta (dnssec kohta))
Could not parse config file , ja sitten alkaa tulemaan sitä konfig tiedostoa rivikaupalla.

Tuon konfig rivien lopuksi se ilmoittaa vielä että :
Could not parse config file "stubby.yml": Generic error
En ymmärrä miksi.

Vaikka se dnssec rivi oli käytössä konffissa, systemctl status stubby.service näytti silti että se on off. Muuten tuo systemctl status kertoi vaan tuota samaa "Could not parse config file "stubby.yml": Generic error"

Tuossa tuo ongelma oikeastaan on, en tiedä miten edetä koska kaikki tuon sinunkin ohjeesi mukaan laitettu. Toki siellä konffissa voi olla virhe ?

Oisko ajatuksia mitä kokeilla ?
 
Parse error : while parsing a block mapping at line 36 column1
Tuo on vielä helppo juttu ongelmaksi, koska stubby ei ollut tyytyväinen konffitiedostoon eikä käyttänyt sitä ollenkaan.
Poistithan ne "> " rivien alusta, esim. näin:
Koodi:
dnssec: GETDNS_EXTENSION_TRUE
EDIT: "< " defaultkonffista, "> " omat muutokset/lisäykset
 
Tuo on vielä helppo juttu ongelmaksi, koska stubby ei ollut tyytyväinen konffitiedostoon eikä käyttänyt sitä ollenkaan.
Poistithan ne "> " rivien alusta, esim. näin:
Koodi:
dnssec: GETDNS_EXTENSION_TRUE
Kyllä, tottakai ja tarkistin # merkit on niissä missä pitää ja toisinpäin.
edit: Arvelinkin että tuossa konffitiedostossa on häikkää, mutta kun keksis vain että mitä.


edit2: Pihole osaa kertoa tämmöistä virhettä :
DNSMASQ_CONFIG : FTL failed to start due to failed to create listening socket for port 53: Address already in use.
 
Viimeksi muokattu:
Pihole osaa kertoa tämmöistä virhettä :
DNSMASQ_CONFIG : FTL failed to start due to failed to create listening socket for port 53: Address already in use.
Tuo voi johtua siitä, että stubby käynnistyy oletusasetuksilla ja varaa portin 53.
Huom. piholea ei tarvitse mitenkään uudelleenkäynnistää tässä harjoituksessa. Ainoastaan asetukset / DNS tarvitsee lisätä tuo uusi lokaali osoite ja stubbyn portti.
Kokeile aloittaa alusta oletuskonffilla ja tee muutokset vaikka rivi kerrallaan. Jos se stubby antaa rivinumeron, missä mättää niin virhe on joko siinä tai sitä edeltävässä muutoksessa
EDIT: Jos stubby ei käynnisty omalla konffilla, niin pysäytä se saman tien, koska oletusportilla (53) se törmää piholen kanssa
 
Minä kokeilen aloittaa alusta rivi kerrallaan
Yksi mahdollinen vikapaikka on tässä
Koodi:
listen_addresses:
  - 127.0.0.1@153
  - 0::1@153
Siinä ylemmässä diffissä oli ylimääräinen "-" ennen listen_addresses, jos kopioit senkin. Tuohon ei siis sen suurempaa modausta tarvitse kuin lisätä osoiterivien loppuun "@153"
EDIT: Tuo voisi olla hyvä ensimmäinen muutos. Viimeisenä muuttaa ne resolverien osoitteet. Välissä stubbyn ei tarvitse sen suuremmin toimia, kunhan se käynnistyy ilman herjoja konffifilusta.
 
Yksi mahdollinen vikapaikka on tässä
Koodi:
listen_addresses:
  - 127.0.0.1@153
  - 0::1@153
Siinä ylemmässä diffissä oli ylimääräinen "-" ennen listen_addresses, jos kopioit senkin. Tuohon ei siis sen suurempaa modausta tarvitse kuin lisätä osoiterivien loppuun "@153"
EDIT: Tuo voisi olla hyvä ensimmäinen muutos. Viimeisenä muuttaa ne resolverien osoitteet. Välissä stubbyn ei tarvitse sen suuremmin toimia, kunhan se käynnistyy ilman herjoja konffifilusta.
En kopioinu mitään suoraan ja nyt taisin löytää vian. Nyt olen siis tilanteessa jossa lisänny rivin kerrallaan ja aina kokeillu tuota komentoa "stubby -i". Alussa ei tule mitään erroria ja jos oikein ymmärrän niin ei lopussakaan kun se ainoa mitä sanoo lopuksi on tämä :

Result: Config file syntax is valid.
Eli eikös tuo tarkoita että se on hyväksytty ?

Vian löysin noista upstream kohdasta. Tai yhden vian, ne ei ollu "jäsennetty" konf tiedostossa oikein, yhdellä rivillä oli 2 välilyöntiä liian vähän ja lisäsin moiset niin yhtä äkkiä se hyväksyikin sen. Tuo on erikoista että tuo konffaaminen on noin hirveän tarkkaa...

Ollaanko nyt sitten missä tilanteessa ? Koitanko tätä kohtaa
"
Siksi kannattaa aluksi käynnistää stubby foregroundille:
stubby -v 3 "
Ja digittää perään toisella ikkunalla ?

@mikajh Nyt kun DIG komentoon sain vielä oikean portin niin toimii. Alkaa olla valmista, laitanko piholeen vielä asetukset ja pitäis toimia ?

Edit
Milläköhän tuon viisaiten saapi käyntiin ?
sudo systemctl start stubby
sudo systemctl enable stubby.service
+ piholeen dns sivulle 127.0.0.1#portti tähän
Entäs sitten ?
 
Viimeksi muokattu:
Result: Config file syntax is valid.
Itsellä kun tein virheen kokeiluissa, niin tuo -i lipun tarkistus ei valittanut mitään. Vasta käynnistys failasi niihin virheilmoituksiin (ilman rivinumeroita). Siksi kannattaa kokeilla lisäksi, että käynnistys onnistuu (eikä tule enää dumppia konffista) ja myös että resolvaus toimii. Sen voi testata millä tavalla tahansa, kunhan pystyy speksaamaan portin.
 
Itsellä kun tein virheen kokeiluissa, niin tuo -i lipun tarkistus ei valittanut mitään. Vasta käynnistys failasi niihin virheilmoituksiin (ilman rivinumeroita). Siksi kannattaa kokeilla lisäksi, että käynnistys onnistuu (eikä tule enää dumppia konffista) ja myös että resolvaus toimii. Sen voi testata millä tavalla tahansa, kunhan pystyy speksaamaan portin.
En hirveästi ymmärtäny mutta kokeillaan menemään :D Editoin vielä tuota aiempaa viestiä, siinä oli kysymys vielä en tiedä kerkesitkö nähdä ?
 
Siinäpä taisi olla kaikki. Katso vielä $ sudo systemctl status stubby
että stubby on paitsi ajossa niin enabloitu, jotta se käynnistyy automaattisesti seuraavassakin bootissa
Katso myös NextDNS:n hallinnsasta (Logs) että sinne tulee kyselyitä.
Aukasin tuon my.nextdns sivun ja heti ilmoitti vihreä pallo All good ! This device is using NextDNS with this configuration.

JES ! Menee kyselyitä logisivulla. Eli nyt vihdoin ja viimein taitaa toimia DoT ja tuo piholesysteemi. Huh.
En tiedä @mikajh miten voisin kiittää tarpeeksi. Kiva että jaksoit lauanta päivän jumpata minun kanssa.
 
stubby:ssa on luotettavuusongelmaa NextDNS:n kanssa. Ei haittaa omassa setupissa, koska toisena DNS resolverina on DnsCrypt.
Laitoin konffiin lisäykset
Koodi:
tls_connection_retries: 5
tls_backoff_time: 300
mutta jos siitä oli jotain hyötyä, niin ainakaan se ei ongelmaa poista eli sitä, että stubby alkaa palauttaa SERVFAIL. Uudelleenkäynnistys auttaa, mutta tuolle pitäisi olla joku automatiikka.
Githubissa oli jotain vastaavia ellei samoja bugeja.
 
stubby:ssa on luotettavuusongelmaa NextDNS:n kanssa. Ei haittaa omassa setupissa, koska toisena DNS resolverina on DnsCrypt.
Laitoin konffiin lisäykset
Koodi:
tls_connection_retries: 5
tls_backoff_time: 300
mutta jos siitä oli jotain hyötyä, niin ainakaan se ei ongelmaa poista eli sitä, että stubby alkaa palauttaa SERVFAIL. Uudelleenkäynnistys auttaa, mutta tuolle pitäisi olla joku automatiikka.
Githubissa oli jotain vastaavia ellei samoja bugeja.
Huomasin että alkoi piholessa näkyä tätä SERVFAIL ja mietin että mistä sekin tulee. Välillä näyy Bogusta punaisella, mutta ei ole haitannut vielä mitään. Täytyy vähä tutkiskella jossain vaiheessa enemmän. Toistaiseksi ainakin kaikki on menny NextDNS logien mukaan 100% DoT:ina.

Ei tuosta varmaan haittaakaan ole ?
Btw, vuorokaudessa kyselyitä tuli 10k ..(Nextdns osas senkin kertoa). Tais se olla kyllä vähän reilumpi vuorokausi. En kellottanu tarkkaan.
 
Ei tuosta varmaan haittaakaan ole ?
En usko, että olisi. Oletuskonffin mukaan retries default = 2 ja backoff_time = 3600. Noilla on se huono vaikutus, varsinkin jos olisi vain yksi forward-osoite, että jos serveri ei vastaa, stubby laittaa kyselyt seis tunniksi, mikä on aika pitkä aika odotella, että netti alkaa taas toimia
 
vasta stubby -v 6 level logitus alkaa tuottamaan jotain, mikä ehkä auttaa selvittämään, mihin stubby jumahtaa
 
vasta stubby -v 6 level logitus alkaa tuottamaan jotain, mikä ehkä auttaa selvittämään, mihin stubby jumahtaa
Jumahtaako useinkin siellä ? Oisko siinä jokin pieni ristiriita sen sinun dnscryptin kanssa ? Täällä on nyt asennuksesta saakka toiminu tuon nextdns kanssa ihan mutkattomasti. Noh, kerran boottasin laitteet kyllä kun jotain pientä hämminkiä oli.

Sinullako tulee oikein kunnon katkoja sen stubbyn kanssa ?
 
Jumahtaako useinkin siellä ? Oisko siinä jokin pieni ristiriita sen sinun dnscryptin kanssa ?
Laitoin erityisen testin pyörimään viiden minuutin välien, mutta se ei tuota suoraan mitään statistiikkaa. Väittäisin että karkeasti vähintään kerran päivässä se jumahtaa, siihen asti että restarttaan.
Dnscrypt pitää piholelle DNS-kyselyt kunnossa siinä rinnalla toisena putkena, joten se ei voi olla syy vaan pikemminkin pelastus.
Nykyisessä konffissa NextDNS:lle menee pelkästään IPv6:lla kyselyt. Voisin vaihtaa kokeeksi IPv4:ään.

Mielenkiintoista on, että näissä stubbyn logeissa ei näy oikein mitään muutosta, vaikka SERVFAILia pukkaa. Odottaisin, että joku näistä reflektoisi jotenkin, kun putki on rikki, mutta mitään ei oikein tapahdu.
Koodi:
[09:11:31.088725] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Resps=   427, Timeouts  =     8, Best_auth =Success
[09:11:31.088759] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Conns=    62, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[09:11:31.088860] STUBBY: 2a07:a8c0:xx:xxxx                       : Upstream   : TLS - Resps=   486, Timeouts  =     0, Best_auth =Success
[09:11:31.088872] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Conns=    62, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[09:13:50.600902] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Resps=   427, Timeouts  =     8, Best_auth =Success
 
Laitoin erityisen testin pyörimään viiden minuutin välien, mutta se ei tuota suoraan mitään statistiikkaa. Väittäisin että karkeasti vähintään kerran päivässä se jumahtaa, siihen asti että restarttaan.
Dnscrypt pitää piholelle DNS-kyselyt kunnossa siinä rinnalla toisena putkena, joten se ei voi olla syy vaan pikemminkin pelastus.
Nykyisessä konffissa NextDNS:lle menee pelkästään IPv6:lla kyselyt. Voisin vaihtaa kokeeksi IPv4:ään.

Mielenkiintoista on, että näissä stubbyn logeissa ei näy oikein mitään muutosta, vaikka SERVFAILia pukkaa. Odottaisin, että joku näistä reflektoisi jotenkin, kun putki on rikki, mutta mitään ei oikein tapahdu.
Koodi:
[09:11:31.088725] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Resps=   427, Timeouts  =     8, Best_auth =Success
[09:11:31.088759] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Conns=    62, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[09:11:31.088860] STUBBY: 2a07:a8c0:xx:xxxx                       : Upstream   : TLS - Resps=   486, Timeouts  =     0, Best_auth =Success
[09:11:31.088872] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Conns=    62, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[09:13:50.600902] STUBBY: 2a07:a8c0::xx:xxxx                       : Upstream   : TLS - Resps=   427, Timeouts  =     8, Best_auth =Success

Täällä tulee tuo SERVFAIL ja BOGUS tuosta duckduckgo osoitteesta ja johtuu varmaan siitä että on päällä se nextdns safesearch päällä. Olettaisin että tuo duckduckgo hakusivu ei tue tuota safesearch ominaisuutta kun blokkaa sivun kokonaan tuo nextdnspalvelu. Helppohan tuo olis kokeilla napauttaa se vain pois päältä ja katsoa mitä tapahtuu.

Mutta sinuna kyllä koittaisin ehdottomasti jo niinkuin sanoitkin niin sitä ipv4 puolta että tuleeko sielläkin katkoksia. Sen jälkeen varmaan stubbyn konffin asetukset uusiks jos ei toimi paremmin ipv4:llakaan. Täällä tosin ei nettikatkoksia ole kyllä tullut ja laitoin ihan ne perusasetukset vain konffiin.

Se konf tiedostohan oli todella kranttu noiden osoitteiden kohdalla kun ylimääräinen välilyönti aiheutti täällä tuskaa alkuun. Mutta ei jumittaminen kyllä konf virheeseen viittaa ollenkaan kun se kerran toimii osan vuorokaudesta. Toivottavasti tuo ipv4 toimis paremmin.
 
@mikajh
Saitko toimimaan, ihan mielenkiinnosta kysyn että minkämoista ongelmaa ja korjausta olet päässyt kehittelemään ja ratkomaan.
 
En vielä kovin kummoista. Vaihdoin muutama tunti sitten kokeeksi stubbyyn Cloudflaren serverit ja huomasin samalla, että IPv4 ei toiminut sen takia, että 853 oli estetty palomuurissa. Katson pysyykö tuo kuinka pitkään toimivana. Lyhyimmät pätkät NextDNS IPv6:n kanssa olivat ihan parin tunnin luokkaa. Katsotaan päivän-parin kuluttua jos sinne päästään.
 
Sen verran tutkin stubbyn -v 7 logia aiemmin, että kun resolvaus loppuu SERVFAILiin, alkaa login Conn_shuts inkrementoitua. Tuon pitäisi tarkoittaa sitä, että remote (NextDNS silloin) katkaisee yhteyden. Koska stubbyn restartilla se alkaa taas toimia, niin paha tuota on laittaa NextDNS:n viaksi
 
Ehkä stubby-ongelma ratkesi jotakuinkin säätämällä idle_timeout:ia vähän lyhemmäksi kuin oletus 10 s. Jopa 5 s voisi olla käytössä. Jos tuo on liian pitkä eikä serveri käytä EDNS0:aa, niin serveri voi katkaista idlaavan yhteyden ja stubby voisi alkaa välttelemään ko. serveriä. Tuo teoria ei kyllä oikein sovi omiin havaintoihin, missä stubby ei tehnyt backoffia serverille vaan jäi pysyvästi limboon
Koodi:
# EDNS0 option for keepalive idle timeout in milliseconds as specified in
# https://tools.ietf.org/html/rfc7828
# This keeps idle TLS connections open to avoid the overhead of opening a new
# connection for every query. Note that if a given server doesn't implement 
# EDNS0 keepalive and uses an idle timeout shorter than this stubby will backoff
# from using that server because the server is always closing the connection.
# This can degrade performance for certain configurations so reducing the
# idle_timeout to below that of that lowest server value is recommended.
#idle_timeout: 10000
#idle_timeout: 9000
idle_timeout: 8500
Mutta tuon kanssa sitä ei ole tapahtunut toistaiseksi kertaakaan. Lisäksi käytössä on myös IPv4, eikä stubby ole siitä vielä pois vaihtanut seuraavaan serveriin IPv6:een
 
Ehkä stubby-ongelma ratkesi jotakuinkin säätämällä idle_timeout:ia vähän lyhemmäksi kuin oletus 10 s. Jopa 5 s voisi olla käytössä. Jos tuo on liian pitkä eikä serveri käytä EDNS0:aa, niin serveri voi katkaista idlaavan yhteyden ja stubby voisi alkaa välttelemään ko. serveriä. Tuo teoria ei kyllä oikein sovi omiin havaintoihin, missä stubby ei tehnyt backoffia serverille vaan jäi pysyvästi limboon
Koodi:
# EDNS0 option for keepalive idle timeout in milliseconds as specified in
# https://tools.ietf.org/html/rfc7828
# This keeps idle TLS connections open to avoid the overhead of opening a new
# connection for every query. Note that if a given server doesn't implement
# EDNS0 keepalive and uses an idle timeout shorter than this stubby will backoff
# from using that server because the server is always closing the connection.
# This can degrade performance for certain configurations so reducing the
# idle_timeout to below that of that lowest server value is recommended.
#idle_timeout: 10000
#idle_timeout: 9000
idle_timeout: 8500
Mutta tuon kanssa sitä ei ole tapahtunut toistaiseksi kertaakaan. Lisäksi käytössä on myös IPv4, eikä stubby ole siitä vielä pois vaihtanut seuraavaan serveriin IPv6:een

Ymmärsin tästä että toiminta meni parempaan suuntaan, mukava kuulla että toimii paremmin.

vasta stubby -v 6 level logitus alkaa tuottamaan jotain, mikä ehkä auttaa selvittämään, mihin stubby jumahtaa

Mihin paikkaan se tallentaa näitä logeja vai tulostaako suoraan komentoriville ? Pitäis vähän seuraavan bootin yhteydessä toisella verkolla seurata mitä tapahtuu, kun tässä toisessa verkossa tuli kans pientä ongelmaa. Stubby käynnistyy bootin jälkeen jumitilaan, mutta sitten täytyy vain vähän restarttailla stubbyä ja odotella niin se lähtee käyntiin kyllä mutta jotain pientä hämminkiä siinä startissa on.

Toisessa verkossa on cloudflare joka ymmärtääkseni toimii ihan kyllä, vaikka 1.1.1.1/help testisivu näyttääkin että DoT ei olisi käytössä. Se dig komento menee sujuvasti läpi eikä silleensä ole suurempaa ongelmaa sekä conf tiedosto kelpaa kyllä, mutta sen käyntiin saaminen bootin yhteydessä vain hieman takkuaa.

Miten sen oikein huomaa parhaiten jos stubby putoaakin pelistä pois ? Pitäiskö netin katketa koska piholessa ei ole muita dns palvelua käytössä kuin vain custom 127.0.0.1#xxxx ?
 
Mihin paikkaan se tallentaa näitä logeja vai tulostaako suoraan komentoriville ?
Vähän kehnot optiot noihin liittyen stubbyssä. Kun haluat käynnistää stubby servicenä ja ihmetellä, miksei se toimi, niin tiedosto stubby.service
esim. hakemistossa /etc/systemd/system/multi-user.target.wants/
ja kun siihen modaat ExecStart=/usr/bin/stubby -l (eli lisäät -l [Service] -osioon)
niin systemctl status stubby
voi näyttää hieman logia.
Kun .service-tiedostoja modaa, pitää tehdä
systemctl daemon-reload
 
Miten sen oikein huomaa parhaiten jos stubby putoaakin pelistä pois ? Pitäiskö netin katketa koska piholessa ei ole muita dns palvelua käytössä kuin vain custom 127.0.0.1#xxxx ?
Jos stubby on ainoa upstream DNS serveri, niin query logissa alkaa tietysti heti näkyä virheet, ja kun sivustojen viimeiset vastaukset (Time To Live) menee ohi, niin "netti lakkaa toimimasta"
 
Oma pihole jotain rupesi sekoilemaan ja gravity blacklistasi iotechin randomisti. Rupesin ihmettelee miksi ei toimi ja katoin query logia niin siellä gravity blocked.
 

Statistiikka

Viestiketjuista
262 920
Viestejä
4 560 904
Jäsenet
75 065
Uusin jäsen
Winter

Hinta.fi

Back
Ylös Bottom