Pi-Hole - mainosblokkeri raspberry pi:stä

[qettyz]

No totta tuo, muutaman kerran on mennyt PiHole nurin ja kyllä on narinaa tullut minun suuntaan. Ei ole ihan vakaimmasta päästä tuo PiHole kuitenkaan.
Nyt on mennyt aika monta viikkoa ilman ongelmia, mutta olen kyllä melkein kerran viikossa bootannut sen kun olen päivityksiä ajellut.

 

[AkQ]

Lopullinen Pi-Hole boksi valmis. Neljä raspia oli vähän liian yliampuva niin päädyin lopulta vain kahteen. 5V 60x25mm Noctua toimii pulssileveysmodulaatiolla äänettömästi.

Ainoat johdot sisään on verkkojohto USB hubiin ja yksi Ethernet kaapeli kytkimeen. Hauska projekti kaiken kaikkiaan.

Tee tuosta guide

 

[Infinity]

Tee tuosta guide

Jossain välissä olisi tarkoitus, pitää eka saada vielä hiukan siistittyä johtoja sopivilla kulma-paloilla.

 

[AkQ]

Imho tuollainen kyhäämäsi boksi pitäisi olla jokaisen kotitaloudessa. Kaksi aparaattia juuri qettyz:in mainitseman narinan takia.

 

[qettyz]

PiHolen sivuilla ihan kivaa juttua mitä kaikkea PiHolen avulla onkaan huomattu verkossa liikkuvan.

 

[qettyz]

Minä nyt pistin kokeiluun crontabiin "0 3 * * * /sbin/shutdown -r now", eli joka aamu 03 reboot.
Jospa tuo vakauttaa PiHolen pyörimään ilman huolen häivää vaikkapa kuukaudeksi, kun välillä on pitempiäkin aikoja kun käyn ssh:lla räpeltämässä. Ei sillä että ongelmia olisi jotenkin paljon kaatuilussa, mutta tuntuu että maks viikon kaks tuo pysyy pystyssä jos ei boottaa.
Eihän tuollainen scripti tietysti mitään kivaa ole, jos yrittää ajella jotain uprecordseja, mutta PiHolen kanssa sellaisia ei kyllä kannata edes haaveillakaan

Edit: voisi tietysti ensin kokeilla vaan pelkkää PiHolen restarttaamista crontabin kautta ….hmm

 

[tkhyla]

Lopullinen Pi-Hole boksi valmis. Neljä raspia oli vähän liian yliampuva niin päädyin lopulta vain kahteen. 5V 60x25mm Noctua toimii pulssileveysmodulaatiolla äänettömästi.

Ainoat johdot sisään on verkkojohto USB hubiin ja yksi Ethernet kaapeli kytkimeen. Hauska projekti kaiken kaikkiaan.

Miten tuo toimii, oletko määritellyt toisen primary DNS:ksi ja toisen secondary DNS:ksi?
Synkkaako nämä kaksi kaikki white & blacki listat keskenään automaattisesti vai ovat täysin itsenäiset?
Mielenkiintoinen projekti. Onko jotain ohjetta jolla tämän voisi kopioda myös itselleen? (jos tuossa on jotain automatiikkaa siis takana)

 

[Infinity]

Miten tuo toimii, oletko määritellyt toisen primary DNS:ksi ja toisen secondary DNS:ksi?
Synkkaako nämä kaksi kaikki white & blacki listat keskenään automaattisesti vai ovat täysin itsenäiset?
Mielenkiintoinen projekti. Onko jotain ohjetta jolla tämän voisi kopioda myös itselleen? (jos tuossa on jotain automatiikkaa siis takana)

Juuri näin, reitittimessä on molemmat erikseen primary/secondary DNS kentissä. Rsyncillä voisi kuulemma synkata Pihole configit, mutta en ole vielä siihen perehtynyt.

 

[tkhyla]

Juuri näin, reitittimessä on molemmat erikseen primary/secondary DNS kentissä. Rsyncillä voisi kuulemma synkata Pihole configit, mutta en ole vielä siihen perehtynyt.

Kun oli ylimääräinen raspia hyllyssä niin teinpä siitä kokeeksi secondary DNS pihole serverin. Täytyy kokeilla paljonko tuonne tulee hittejä jotka ei siis jää Primary DNS serveriin. Otin pihole backupin listoista ja palautin uuteen. Jos virittelet nuo jotenkin synkkautumaan automaattisesti niin kerro

 

[Paris]

.

 

[tkhyla]

Tämä kiinnostaa! Kun saat jotain tuloksia miten liikenne jakautuu primaryn ja secondaryn kesken, niin laita jakoon.

Tämä kiinnostaa itseänikin myös. Nyt on pyörinyt uusi secondary pihole noin 24 tuntia. Tässä ajassa Primary pihole on kerännyt total queries 39300 hittiä ja secondary samassa ajassa 2700.
Tämä oli itselleni yllätys. Olin kuvetellut, että secondaryä käytetään vain silloin jos Primary on poissa pelistä. Aikaisemmin olin määritellyt reitittimen asetuksista Primary DNS palvelimeksi piholen ja secondary DNS:ksi cloudflare 1.1.1.1. Aikaisemmin osa liikenteestä on tämän testin mukaan mennyt suoraan secondary serverille ohi piholen. Nyt reitittimessä ei ole asetettu ollenkaan ulkoista DNS palvelua. Vain kaksi pihole serveriä.

Joku joka tietää DNS toiminnasta enemmän voisi selittää miten primary ja secondary eroaa. koska käytetään secondaryä?

 

[Urbanproof]

Se itseasiassa hieman vaihtelee käyttöjärjestelmästä ja versiosta toiseen. Syitä siihen voi olla monia, jos esim. Primary dns vastaa kerran-pari hitaasti, se voi aiheuttaa sen että käyttöjärjestelmä ohjaa seuraavat requestit secondary dns:lle joksikin aikaa.

E: Esim. MacOS versiot ennen 10.6 tai 10.7 taisivat ohjata requestit annetussa järjestyksessä, ja vasta primaryn mennessä täysin hiljaiseksi ohjasivat seuraavaan. Nykysin se vaihtelee sen mukaan, mistä käyttöjärjestelmä kulloinkin arpoo vastauksen saavansa nopeiten, ensisijaisesti kuitenkin ensimmäsienä määritettyyn.

 

[111]

.

 

[Urbanproof]

Mä veikkaan että(jos itse olisin käyttöjärjestelmän tekijä), niin kysyisin kaikilta tiedossa olevilta dns-palvelimilta säännöllisesti (ylläpitäisin yksinkertaista nopeus-tilastoa) ja myös sen lisäksi silloin kun kyselyyn kulunut aika kasvaa jonkun trigger-arvon verran. Mutta siis veikkaan vaan

Täydellisessä maailma kyllä näin, mutta ihmisillä on tapana luottaa siihen että kaikki requestit menevät primarylle joten sitä täytyy suosia vaikka se hieman hitaampi olisikin joskus. Muutenhan noita tosiaan kannattaisi ohjata aina sinne missä on vähiten kuormaa.

 

[Asiantuntija]

Siis olette säätäneet käyttöjärjestelmästä suoraan nuo dns-palvelimet? Onko kellään reitittimeen asetettuna kahta piholea dns-servuiksi? Tai no osa niistäkin toimii eri tavalla ja osa jakaa kuormaa ja osa ei.
e: Olihan tuolla ylempänä kerrottu, että reitittimeen asetettu primary ja secondary dns:t.

 

[Urbanproof]

Siis olette säätäneet käyttöjärjestelmästä suoraan nuo dns-palvelimet? Onko kellään reitittimeen asetettuna kahta piholea dns-servuiksi? Tai no osa niistäkin toimii eri tavalla ja osa jakaa kuormaa ja osa ei.

Hyvä tarkennus. Käyttöjärjestelmällä tarkoitin tässä tapauksessa mitä tahansa käyttöjärjestelmää siinä laitteessa joka sen viime kädessä päättää mihin requestit lähteee, oli se sitten Windows tai reitittimen OS. MacOS oli vain esimerkkinä, samalla tavalla noissa on kaikissa jopa eri versioiden välillä vaihtelua.

Tämä siis kokemuspohjaisesti, viisaammat korjatkoot.

 

[111]

.

 

[Edman]

Pihole pyörii tällä hetkellä ubuntu koneessa, joka ajaa kotiteatterin virkaa. Toisinaan pihole vetää jostain syystä itsensä hirteen kaataen koko verkon (näkyy tosin aktiivisena).

Onko tähän jotain fixiä jota kannattaisi kokeilla ettei muija kävisi uudestaan päälle aiheutuneesta harmista?

E: reitittimestä on dhcp palvelin pois päältä.

 

[Grazer]

Itsekin tuli Pihole asenneltua Ubuntu Serveriin. Saa nähdä, pärjääkö pelkästään tällä vai pitääkö pykätä secondary DNS myös. Sen voisikin sitten tehdä raspilla.

 

[qettyz]

Minä ratkaisin asian näin.

restartdns.sh mitä ajetaan crontabilla joka yö 03.

#!/bin/sh
/usr/local/bin/pihole restartdns >/dev/null 2>&1

chmod a+rx restartdns.sh

sudo crontab -e

* 3 * * * /home/pi/restartdns.sh

EDIT: ei niin kauaa ole tuo ollut pyörimässä, että tietäisin auttaako tuo satunnaisiin PiHolen kaatuiluihin.

 

[tkhyla]

Pihole pyörii tällä hetkellä ubuntu koneessa, joka ajaa kotiteatterin virkaa. Toisinaan pihole vetää jostain syystä itsensä hirteen kaataen koko verkon (näkyy tosin aktiivisena).

Onko tähän jotain fixiä jota kannattaisi kokeilla ettei muija kävisi uudestaan päälle aiheutuneesta harmista?

E: reitittimestä on dhcp palvelin pois päältä.

Itse en ole kertaakaan törmännyt Pihole jumiin. Pyörinyt jo varmaan kohta pari vuotta Raspissa ilman mitään ongelmia. DHCP:tä en käytä piholesta vaan tuon hoitaa Unifi USG. Nyt tosiaan pyörii rinnalla toinen secondary DNS:nä ja juuri kun katsoin niin viimeisen 24h aikana tullut 5500 hakua. Aika paljon mielestäni menee ohi primary dns:n. Kuten yllä oli puhetta niin eri OS:t käyttää ilmeisesti erilailla DNS kyselyitä.

 

[Infinity]

Jos virittelet nuo jotenkin synkkautumaan automaattisesti niin kerro

Dual pihole sync 2.0 : pihole

 

[Grazer]

Mitenkäs tuon Piholen DNS Conditional forwardingin saisi toimimaan TP-Linkin routteria (Archer C5 1200) käyttäessä, kun tuossa TP-linkissä ei ole mahdollista määritellä local domainia mihinkään?

DHCP-palvelimena on tuo TP-Link.

Jostain syystä Piholen statseissa Philipsin Hue Gateway, Sony Xperia ja työantajan läppäri eivät listaudukaan saamiensa IP-osoitteiden perusteella, vaan näiden kaikki DNS-pyynnöt listautuvat xx.xx.xx.xx.elisa-laajakaista.fi -osoitteen alle.

 

[Asiantuntija]

Mitenkäs tuon Piholen DNS Conditional forwardingin saisi toimimaan TP-Linkin routteria (Archer C5 1200) käyttäessä, kun tuossa TP-linkissä ei ole mahdollista määritellä local domainia mihinkään?

DHCP-palvelimena on tuo TP-Link.

Jostain syystä Piholen statseissa Philipsin Hue Gateway, Sony Xperia ja työantajan läppäri eivät listaudukaan saamiensa IP-osoitteiden perusteella, vaan näiden kaikki DNS-pyynnöt listautuvat xx.xx.xx.xx.elisa-laajakaista.fi -osoitteen alle.

Tarkistappa tuon TP-Linkin asetukset vielä pariin kertaan ajatuksen kanssa. Ei tuo ole normaalia, että sisäverkon laitteiden dns-kyselyt näkyvät ulkoverkon osoitteen alla.

 

[Grazer]

Tarkistappa tuon TP-Linkin asetukset vielä pariin kertaan ajatuksen kanssa. Ei tuo ole normaalia, että sisäverkon laitteiden dns-kyselyt näkyvät ulkoverkon osoitteen alla.

Tuo ihmetyttää itseänikin, koska nuo kaikki laitteet näkyvät TP-Linkin DHCP-listalla, IP-osoite ja hostname

EDIT: Enpä kyllä keksi tuolta mitään säätämisen arvoista/mitään mikä voisi olla pielessä.

EDIT2: Katsoppas, nyt sattui vasta silmiin että onhan tuossa DHCP-asetuksissa mahdollisuus määritellä sisäverkon domain. Kokeillaanpa

EDIT3:No nyt pelaa kun määritteli default domainin TP-Linkin asetuksiin. Siinä vaan kun lukee että optional, niin olen aiemmin antanut olla tyhjänä

 

[Asiantuntija]

Tuo ihmetyttää itseänikin, koska nuo kaikki laitteet näkyvät TP-Linkin DHCP-listalla, IP-osoite ja hostname

EDIT: Enpä kyllä keksi tuolta mitään säätämisen arvoista/mitään mikä voisi olla pielessä.

EDIT2: Katsoppas, nyt sattui vasta silmiin että onhan tuossa DHCP-asetuksissa mahdollisuus määritellä sisäverkon domain. Kokeillaanpa

EDIT3:No nyt pelaa kun määritteli default domainin TP-Linkin asetuksiin. Siinä vaan kun lukee että optional, niin olen aiemmin antanut olla tyhjänä

Jaa. Ei näköjään ollutkaan mitenkään haitallista/haittaavaa.

 

[Grazer]

Piti ottaa tuo conditional forwarding toistaiseksi pois päältä, kun jostain syystä se lisäsi 2-3 sekuntia viivettä (selaimen tilarivillä lukee resolving host) sellaisiin sivuihin, joiden osoitetta ei cachesta löydy.

Onko joku käyttänyt tuota conditional forwardingia?

 

[Stemmi]

Ainakin Orange Pi Zeron kautta kierrätettynä verkkoliikenne menee solmuun jos yrittää käyttää VPN:ää.

Tähän olettamukseen on tultu Vpn.ac-palvelun kohdalla. Jostain kumman syystä yhteys korjautuu pi-holen hetkellisellä poiskytkennällä, mutta logeista ei tuolle käytökselle löydä syytä kun ongelma on satunnainen

Lähetetty minun Z2 Plus laitteesta Tapatalkilla

 

[qettyz]

Minä ratkaisin asian näin.....restartdns….crontab...joka yö 03....

Ei ole ollut ainakaan vielä minkäänlaisia ongelmia PiHolen jumittumisessa, mutta ompa nuo jumittumiset olleet aiemmin hyvin satunnaisia jotenka eipä voi oikein sanoa kuin kk kahden päästä että josko noita kaatuiluja ei ole yhtään ollut PiHolella. Nyt Pi:llä pyörii myös kotiverkon Minecraft palvelin(Bukkit) lapsille, niin tuon käyttöaste hieman noussut, mutta vielä on kevyttä silti kun loadeja katselee.
​

Ainakin Orange Pi Zeron kautta kierrätettynä verkkoliikenne menee solmuun jos yrittää käyttää VPN:ää.
Tähän olettamukseen on tultu Vpn.ac-palvelun kohdalla. J

F-Secure Freedom on täällä ollut enemmän ja vähemmän käytössä ipadillä ja se ei ole vaikuttanut mitenkään PiHolen toimintaa Rpi3 "koneella".

 

[Paris]

.

 

[Infinity]

Asus RT-AC68U hoitaa DHCP:n ja DNS Primary ja Secondary osoittaa tätä Piholea. Hyvin on toiminut, mutta nyt teidän kokeilujen jälkeen laitoin DNS Secondaryn osoittamaan NAS:in Piholea, kun ehtinyt sitä vielä purkaa. Katsotaan miten minulla jakaantuu Primaryn ja Secondaryn välillä...

AC68U vuotaa sitten jotkut DNS pyynnöt Pi-holen ohi, esim Chromecastistä ja Nintendon konsoleista joissa on koodattu DNS osoitteet firmikseen suoraan. Myös jotkut Googlen Android apit menevät suoraan Pi-holen ohi.

Näillä iptables komennoilla saa ohjattua kaikki DNS pyynnöt Pi-holeen (vaihda IP):

iptables -t nat -A PREROUTING -i br0 -p udp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p tcp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -j DNAT --to 192.168.1.10
iptables-save

 

[Paris]

.

 

[Infinity]

Myös merlin?

Jep. Merlin itsellä käytössä ja vaatii nuo rimpsut.

En tiedä miten noita voisi muuttaa kahta Pi-holea varten, mutta yhdellä toimi loistavasti ja alkoi Pi-holen lokeihin tulemaan DNS pyyntöjä jotka reititin päästi ennen läpi.

 

[Paris]

.

 

[Infinity]

Ajaako nämä rimpsut Asuksessa määritettyjen Primary ja Secondary DNS määrityksen yli? Ja kun rimpsuissa on Primary Pi-hole IP, niin Secondarylle ei mene sitten mitään?

Kuten kirjoittelin niin secondary ei tosiaan näillä toimi, tai toimii mutta sitten kaikki secondaryn DNS ohjaukset menee takaisin primääriin, eli ei järkeä pitää kahta noilla ohjauksilla. Omat iptables taidot ei riitä kahteen eri osoitteeseen ohjaus kaikkine ehtoineen.

Nuo rimpsut toimii kun WAN DNS1 kohdassa on yksi Pi-hole. Jos joku iptables velho haluaa noita rimpsuja parantaa niin kuulolla ollaan.

 

[Lagittaja]

Ajaako nämä rimpsut Asuksessa määritettyjen Primary ja Secondary DNS määrityksen yli? Ja kun rimpsuissa on Primary Pi-hole IP, niin Secondarylle ei mene sitten mitään?

Ajaa. iptables NAT jutut pyörii reitityksessä ja DHCP on local palvelu.

Jos teillä on kaksi pi-holea niin sitten secondary ei saa mitään.
Jos tekee kaksi iptables rimpsua joista yksi ohjaa .10 ja toinen ohjaa .11 niin kun se DNS paketti tulee niin se menee siihen ensimmäiseen .10 osoitteeseen kun se on ensimmäisenä siinä listassa.

En ole iptables velho ja en kyllä nyt yhtäkkiä keksi miten tämän saisi toimimaan kahdella pi-holella..
Mutta...--source (ja myös --destination) voi olla network name, host name, pelkkä IP osoite tai IP osoite alue.
Eli --source tai --destination ei ole ongelma.
Ongelma on se DNAT --to x.x.x.x. Se voi olla vain yksi IP.

Pi-Hole tarvitsee kyllä kipeästi sen "sisäänrakennetun" high-availability ratkaisun. Mutta mitä DNATtiin tulee niin eipä se HA ratkaisu siihen auta.
Tähän nyt tarvittaisiin jokin load balancing kikkare väliin? Eli DNAT ohjaa paketin load balancing IP:hen joka sitten ohjaa jollain logiikalla PH1:lle tai PH2:lle?

Edit: Tosin mainitaan -m statistic --mode nth --every x. Googleen vaikka iptables round robin. Pitäkää hauskaa. Minulla ei ole laitteistoa millä tätä testata mutta mitä nyt teoriassa tätä pyörittelen päässäni niin kaksi rimpsua eri --to osoitteella voisi toimia jos käyttää tuota statistic countteria laskemaan paketteja ja ohjamaan paketteja? Eikä tarvitse edes määrittää IP osoite aluetta noihin source/destination kun voi käyttää luonnostaan useampaa rimpsua.
Paitsi että pitää jos haluaa että round robin toimii mahdollisimman hyvin? Jos nuo alla olevat rimpsut käytössä ja oikeasti toimivat niin jos laite lähettää dns kyselyn .11 niin se menee aina sinne.
Jos määrittää .10-.11 alueen niin ihan sama kumpaa osoitetta laite sattuu käyttämään? Se menee aina entten tentten joko .10 tai .11 riippuen menikö edellinen .10 vai .11.

statistic
This module matches packets based on some statistic condition. It supports two distinct modes settable with the --mode option.
Supported options:

--mode mode
Set the matching mode of the matching rule, supported modes are random and nth.
[!] --probability p
Set the probability for a packet to be randomly matched. It only works with the random mode. p must be within 0.0 and 1.0. The supported granularity is in 1/2147483648th increments.
[!] --every n
Match one packet every nth packet. It works only with the nth mode (see also the --packet option).
--packet p
Set the initial counter value (0 <= p <= n-1, default 0) for the nth mode.

Man page of iptables-extensions

Eli voisiko tämä esimerkiksi toimia?

iptables -t nat -A PREROUTING -i br0 -p udp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p udp ! --source 192.168.1.11 ! --destination 192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11
iptables -t nat -A PREROUTING -i br0 -p tcp ! --source 192.168.1.10 ! --destination 192.168.1.10 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p tcp ! --source 192.168.1.11 ! --destination 192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11

Logiikka tässä että ensimmäiset kaksi on udp ja toiset kaksi on tcp.
Ensimmäinen rimpsu menee "entten tentten..", käsittelee siis joka toisen paketin ja toinen rimpsu käsittelee jokaisen paketin eli ne mitkä jää ensimmäiseltä yli (joka toinen).

Tämä on sitten ihan hakuammuntaa, vedin tuon rimpsun kasaan tämän perusteella
round robin to three ports on the same host with iptables
Tuossa esimerkissä -m statistic moduulia käytetään ohjaamaan paketit menossa tcp 9000 joko tcp 9001, 9002 tai 9003.

I

 

[Infinity]

snip

Rimpsut meni reitittimeen tuollaisenaan sisään ainakin ilman virheitä, testailen.

Edit: Alkoi tulemaan Unknown tuloksia lokiin reitittimestä ja kyselyiden määrät nousi melko rajusti, jokin ei ihan tykkää.

 

[Lagittaja]

Rimpsut meni reitittimeen tuollaisenaan sisään ainakin ilman virheitä, testailen.

Muokkailinkin tuota viestiä, sanoin ensin että --source tai --destination ei tarvitsisi IP osoite aluetta mutta jos laite sattuu käyttämään .11 niin se DNS kysely menee aina sinne.
En tiedä minkälaisella hyötysuhteella se round robin toimii noilla ylläolevilla säädöillä. Suurinosahan DNS kyselyistä menee aina primary osoitteeseen joten alla oleva säätäminen saattaa olla turhaa.

Mutta mainitaan nyt kuitenkin.

iprange
This matches on a given arbitrary range of IP addresses.
[!] --src-range from[-to]
Match source IP in the specified range.
[!] --dst-range from[-to]
Match destination IP in the specified range.

Man page of iptables-extensions

Ja näiden --src/dst-range kaveriksi tarvitaan vielä --match iprange kikkare.. Tarvitaanko se myös ! --dst-range eteen? En tiedä. Ehkä? Laitetaan varmuuden vuoksi

iptables -t nat -A PREROUTING -i br0 -p udp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p udp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11
iptables -t nat -A PREROUTING -i br0 -p tcp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -m statistic --mode nth --every 2 --packet 0 -j DNAT --to 192.168.1.10
iptables -t nat -A PREROUTING -i br0 -p tcp --match iprange ! --src-range 192.168.1.10-192.168.1.11 --match iprange ! --dst-range 192.168.1.10-192.168.1.11 --dport 53 -j DNAT --to 192.168.1.11

Hyhhyh, menee aina vain sekavamman näköiseksi..

 

[qettyz]

Tosiaan kun tästä kaatuilusta ollut kokemuksia ittellä, niin asiaan voi suuresti vaikuttaa se että Pi3 on Wifi yhteydellä reitittimessä. Sehän saattaakin olla esim wlan ajurit mitkä kyykkää tms kun datapakettia tulee ahkeraan.

 

[IcePen]

Tosiaan kun tästä kaatuilusta ollut kokemuksia ittellä, niin asiaan voi suuresti vaikuttaa se että Pi3 on Wifi yhteydellä reitittimessä. Sehän saattaakin olla esim wlan ajurit mitkä kyykkää tms kun datapakettia tulee ahkeraan.

Muuten lämpö vaikuttaa Wlan yhteyden vakautueen joten jos se P3 on esim. suht umpinaisessa muovikotelossa niin että myös se Wlan pääsee lämpenemään (vaikka välillisesti) se voi aiheuttaa Wlan yhteyden epävakautta/siirtovirheitä.

 

[qettyz]

Muuten lämpö vaikuttaa Wlan yhteyden vakautueen joten jos se P3 on esim. suht umpinaisessa muovikotelossa niin että myös se Wlan pääsee lämpenemään (vaikka välillisesti) se ovi aiheuttaa Wlan yhteyden epävakautta/siirtovirheitä.

Kolmeen piiriin olen jäähyt laittanut tuohon ja avonaisessa kotelossa majailee, eikä tuo nyt mitenkään jumitellut kuumina kesäpäivinä. Hyvin voi kuitenkin olla wlaniin liittyviä olleet ne muutamat jumit. Muistaakseni ekan kerran kun meni jumiin koitin pingillä vastausta ei, ei kirjautunut ssh:lla jne, että enemmänkin se nurin mennyt kuin pelkkä PiHole, tuohonhan tosiaan riittäisin pelkkä wlanin kaatuminen Pi:ssä.
Siinä mielessä mielenkiintoista miten tulevat kuukaudet menee ja auttaako yhtään tuo että käynnistän PiHolen dns palvelun öisin uudelleen, itse Pi:tä en reboottaa.

 

[JPAK]

Tälläinen typerä kysymys tässä pyörii mielessä ennen kuin vaihdan tuon minun retropien tähän pieholeen: Häiritseekö/monimutkaistaako tämä omaa teamspeak3 serverin pitämistä? Tällä hetkellä oma ts3 servu pyörii siis omalla koneella tuon no-ip:n tarjoaman dns palvelun kautta.

 

[Asiantuntija]

Häiritseekö/monimutkaistaako tämä omaa teamspeak3 serverin pitämistä?

Ei.

 

[Paris]

.

 

[angle]

Onko mitään eroa sillä että primary ja secondary osoittaa samaan osoitteeseen versus, että käyttää vain primarya ja secondary yms. tyhjiä?

 

[olkitu]

Onko mitään eroa sillä että primary ja secondary osoittaa samaan osoitteeseen versus, että käyttää vain primarya ja secondary yms. tyhjiä?

Ei ole mitään merkitystä eikä edes hyötyä olla kahta DNS:sää joka ohjaa samaan paikkaan... Kun DNS nurin on niin nurin se on. Mutta kotikäytössä riittää yksi kylläkin - harvoin se nyt rikki menee ja yhteys katkeaa siihen. Ja korjaaja on heti paikalla.

 

[Asiantuntija]

Ei ole mitään merkitystä eikä edes hyötyä olla kahta DNS:sää joka ohjaa samaan paikkaan... Kun DNS nurin on niin nurin se on. Mutta kotikäytössä riittää yksi kylläkin - harvoin se nyt rikki menee ja yhteys katkeaa siihen. Ja korjaaja on heti paikalla.

Mutta, jos se raspberrypi sattuisi jostain syystä kuolemaan niin yksikään url ei toimisi mikäli reitittimestä tai kaikista koneista on se raspi asetettuna ainoaksi dns-resolvaajaksi. Ei tuo kyllä ole mikään kovin suurella todennäköisyydellä tapahtuva asia, mutta varmennus on aina hyvästä. Nopeana korjauksena voi muuttaa reitittimen asetuksista dns:n vaikka 1.1.1.1 tai 8.8.8.8, vaikka etänä ja laittaa sen piholen kuntoon sen jälkeen. Tosiaan muistikortit on raspberrypi:n heikoin lenkki. Muuten sen pitäisi kestää käyttöä hyvin.

Joku kertoi tässä threadissä käyttävänsä piholea wlanin yli eli siis raspi on yhdistettynä tukiasemaan wlanin kanssa. Se ei todellakaan ole suositeltavaa. Enkä itse ainakaan haluaisi ylimääräistä 5-30ms viivettä jokaiseen dns-kyselyyni. Ja kuten kyseinen käyttäjä kertoi niin myös yhteys on epävakaa.
e: En ymmärrä lukemaani.

 

[olkitu]

Mutta, jos se raspberrypi sattuisi jostain syystä kuolemaan niin yksikään url ei toimisi mikäli reitittimestä tai kaikista koneista on se raspi asetettuna ainoaksi dns-resolvaajaksi. Ei tuo kyllä ole mikään kovin suurella todennäköisyydellä tapahtuva asia, mutta varmennus on aina hyvästä. Nopeana korjauksena voi muuttaa reitittimen asetuksista dns:n vaikka 1.1.1.1 tai 8.8.8.8, vaikka etänä ja laittaa sen piholen kuntoon sen jälkeen. Tosiaan muistikortit on raspberrypi:n heikoin lenkki. Muuten sen pitäisi kestää käyttöä hyvin.

Joku kertoi tässä threadissä käyttävänsä piholea wlanin yli eli siis raspi on yhdistettynä tukiasemaan wlanin kanssa. Se ei todellakaan ole suositeltavaa. Enkä itse ainakaan haluaisi ylimääräistä 5-30ms viivettä jokaiseen dns-kyselyyni. Ja kuten kyseinen käyttäjä kertoi niin myös yhteys on epävakaa.

Sitten kaksi raspia ja pi-holea verkkoon niin ei ongelmaa mutta ei ole hyötyä että primary ja secondary ovat sama raspi

 

[user9999]

Laiton kaksi piholea pystyyn. MacOS Mojave ja Windows 10 1809 ja noiden verkkokortteihin nuo pihole koneiden ip:t primary ja secondary kenttiin. Windows 10 koneelta menee kyselyjä reilu 10% tuolle secondary pihole koneelle. MacOS koneelta ei mene yhtään. Ajoin tuon primary piholen nurin niin sitten menee macOS koneelta kyselyjä secondary pihole koneelle.
Tunnin verran tuota testailin.

 

[Infinity]

Primary/Secondary ei siis ole suoranaisesti mikään load-balancing ratkaisu, vaan juurikin sitä varten jos primääri menee nurin.

Jos molemmat on hengissä niin Secondaryyn menee jokunen kysely jos Primary ei vastaa 5-10ms kuluessa (saattaa olla toinen DNS kysely käsittelyssä).