Pi-hole synkronointi (Nebula Sync) – tekninen projektikuvaus
Yleiskuva ja tavoite
Tässä projektissa rakennetaan kahden Pi-hole-instanssin välinen synkronointi, jotta kotiverkon primääri-Pi-hole (LAN) ja VPS:llä ajettava varainstanssi pysyvät yhtenäisinä ilman käsityötä.
- Primääri: kotiverkko (asiakkaat käyttävät vain tätä DNS:ää)
- Toissijainen: VPS (failover / varalla, ei jaeta DHCP:llä asiakkaille)
- Tavoite: samat blocklistit, allowlistit, asiakasryhmät ja muut Pi-hole-asetukset molemmille
Valittu ratkaisu
Synkronointiin käytetään Nebula Sync -työkalua, joka hakee ja päivittää Pi-hole v6
-instanssin asetuksia API:n kautta. Synkronointi ajetaan ajastetusti (cron) ja konfiguroidaan
ympäristömuuttujilla (.env), jotta salaisuuksia ei tarvitse kirjoittaa koodiin.
Arkkitehtuuri (käytännön malli)
- LAN Pi-hole: “source of truth” (ensisijainen totuus)
- VPS Pi-hole: replika, joka pidetään ajan tasalla
- Yhteys: synkka käy palvelimelta toiseen HTTPS:n yli (Pi-hole API)
Käytännössä tämä on tarkoituksella “yksi johtaja, yksi seuraaja” -malli: asiakkaat käyttävät vain LAN-DNS:ää, mutta varakone on valmiiksi synkattu siltä varalta, että LAN-ympäristössä tapahtuu jotain yllättävää (ihmisten suosikki harrastus).
Synkattavat kohteet
Synkronoinnissa kannattaa rajata mukaan vain ne osa-alueet, jotka aidosti halutaan identtisiksi. Tyypillisesti mukaan otetaan:
- adlistit / blocklistit (Gravity-lähteet)
- allowlist / denylist -domainit
- ryhmät ja “group management” -määritykset (tarvittaessa)
- paikalliset DNS-merkinnät, jos ne halutaan molemmille samoina
Sen sijaan esimerkiksi loki- ja query-data pidetään instanssikohtaisena (eli niitä ei yritetä synkata), koska se on sekä turhaa että sotkevaa.
Turvallisuus ja rajaukset
- API-avaimet: vain palvelimelle, ei koskaan julkiseksi repossa tai HTML:ssä
- IP-rajoitus: Pi-hole admin/API näkyviin vain luotetusta IP:stä tai VPN:stä
- HTTPS/TLS: mieluummin aina, etenkin VPS-yhteyksissä
- Least privilege: synkalle vain se pääsy mikä tarvitaan
- Varmistus: ennen “push”-synkkaa ota talteen molempien instanssien nykytila
Ajastus ja valvonta
Synkronointi ajetaan tyypillisesti cronilla esimerkiksi 1–4 kertaa vuorokaudessa tai aina blocklist-päivityksen jälkeen. Järkevä toteutus sisältää myös:
- lokituksen tiedostoon (onnistui/epäonnistui + virheilmoitus)
- “dry run” / testiajo ennen ensimmäistä oikeaa pushia
- hälytys sähköpostiin, jos synkka epäonnistuu
Testaus (miten varmistetaan että tämä toimii)
- tee pieni muutos primääriin (esim. yksi allowlist-domain)
- aja synkka
- varmista, että sama muutos näkyy replika-instanssissa
- tee DNS-testit molemmille (esim. tunnettu mainosdomain, ja varmistus että se blokataan)
Nykytila ja seuraavat askeleet
- synkronointityökalu valittu ja arkkitehtuurimalli päätetty
- seuraavaksi: varmistetaan API-rajaukset ja ajastus sekä dokumentoidaan palautuspolku
- lopuksi: tuotantoajot + valvonta (ettei tämäkin jää “huomiseen”)