Kā izdzīvot, ja nomirst PiHole, bet tevis nav mājās?
Aiziet, tehniskajā jūriņā. Nekā sevišķi sarežģīta, bet neinteresenti var nelasīt.
Šodien atkal nostrādāja, jo NAS atbrauca sistēmas atjauninājums. Tas atgādināja, ka varbūt ar šo jāpadalās tālāk par tviteri. Lai gan - diez vai mana bloga kontekstā "tālāk par tviteri" ģeld.
Mājās izmantoju PiHole. Tā ir tāda lietiņa, kura tēlo lokālo DNS serveri, bet aktīkvi filtrē ārā ļaunās lietas. Piemēram, reklāmu trekerus.
Iepriekš šitā uzparikte man stāvēja uz maziņā Raspberry Pi Zero W, kur tai arī bija sākotnējā vieta, jo ... nu ... Pi. Tacč, kopš pāris reizes tas nomira, pārliku uz savu NAS (Synology, draudzīgi saukts par Turekli). Tur tas griežas docker konteinerī un nevienu neaiztiek (viņu gan daudzi aiztiek).
Mājinieku tīkls man ir sakonfigurēts caur DHCP. Arī DNS servera IP adrese tiek izsniegta visiem tīkla biedriem caur DHCP.
Taču, kā jau nereti gadās, - ja nu pēkšņi PiHole nomirst, tad tam ir nepatīkams blakusefekts. Mājinieki nāk tevi informēt par to, ka viņim, rau, nestrādājot internets. Vēl draudzīgāk viss notiek, ja tu neesi mājās un nevari salabot. Un, ja vēl tas ir darbadienā...
No tādām lietām, kā rāda dzīves pieredze, vēlams izvairīties. Es teiktu, ka tas jāieraksta Satversmē. Jebkuram risinājumam, kura salabošanai ikdienā vajag tavu klātbūtni, jābūt tādam, ka tas salabojas pats arī tad, kad kāda no komponentēm nosprāgst. Un tas nozīmē izdomāt kļūmjpārlēci. Senlatvieši to sauc par failover.
Raugi, laiku pa laikam tomēr sanāk to pašu Synology izslēgt, tam var kaut kas neuzstartēties, utt. Kā jau teicu, arī RaspberryPi var beigt savas ikdienas gaitas. Tad arī interneti mājās apstājas. Informēju - tas nav labi.
Pirmā iterācija bija ar skriptu uz MikroTik rūtera laiku pa laikam raudzīt vai PiHole dzīvs. Ja nē, tad mainīt visu konfigurāciju iekš DHCP un cerēt, ka visas iekārtas laicīgi attapsies pajautāt pēc jaunās DHCP konfigurācijas. Tas strādāja. Slikti, bet strādāja.
Strādāja un gruzda. Iekšā grauza sajūta, ka kaut kas nav labi. Nav līdz galam. Nav smuki. Nav garantēti. Viss nenotiek tā "čik - un gatavs". Kaut kas jāgaida, kaut kas lēnām atgūstās.
Otrā iterācija bija nedaudz vienkāršāka un drošāka.
Uz tā paša MikroTik rūtera ieslēdzam DNS servisu, kuram norādam, ka tas tālāk visu padod uz mūsu PiHole. Šis pats DNS tiek izmantots arī visā mājas tīklā. Jaunais skripts laiku pa laikam ķīķerē PiHole. Ja tas nomirst, tad nomaina upstream DNS serverus uz publiskajiem (šajā gadījumā 1.1.1.1 un 8.8.8.8). Kad vietējais PiHole parādās atpakaļ, nomainam uz to.
Papildus tam, ja nu mums tāda pēkšņa klupne, tad nosūtam arī ziņu saimniekam caur Telegram. Pēc tam, kad esam nomainījuši DNS, protams. Jo, nu, ... var neatnākt :)
Abas MikroTik skriptu versijas ir pieejamas publiski.
2022. gada 19. janvārī, plkst. 10:59
A tups jautājums... DNSam jau kā tā nav fallback iespējas? Nereti ir redzami sarakstiņi ar vairākām adresēm.
2022. gada 19. janvārī, plkst. 12:00
Vairāki norādītie DNS serveri strādā rindā. Ja pirmais neatbild, tikai tad tiek ņemts otrais. Tas noteikti radīs problēmas, ja būt taimauts, bet labāk tā nekā, ja nestrādā pavisam :)
2022. gada 19. janvārī, plkst. 12:05
Nu, tieši tā. Tas arī ir tas, ko šeit vajag, ne?
2022. gada 19. janvārī, plkst. 12:09
Nē, skripta būtība ir tāda, lai viss strādā visu laiku pēc labākās sirdsapziņas, nevis lēnāk, ja kaut kas nomirst.
2022. gada 19. janvārī, plkst. 14:24
Nu, jā, lai arī es nezinu, cik liela sanāk tā aizture. No otras puses, ja pa vidu enīvei ir Microtik DNS (kurš tālāk prasa vai nu PiHole, vai 1.1.1.1, kurš pirmais pieejams), tad IMHO vajadzētu strādāt samērā veikli enīvei, jo Microtiks jau responses iekešos. Un nevjadzēs nekādus maģiskus skriptus. Tiesa, notifikācija uz Telegramu nebūs. :)
2022. gada 19. janvārī, plkst. 14:28
Nu ne gluži.
Variants bez MT
Visām iekārtām ir uzlikts dns '192.168.1.5, 1.1.1.1, 8.8.8.8'. Pirmais noklājas. Internets kļūst ļooooti lēns, jo visas iekārtas no sākuma prasa vai pihole dzīvs (viņas to dara vienmēr) un tikai pēc tam izmanto sekundāro un triāro.
Variants ar MT
Visām iekārtām uzlikts dns '1.1.1.1'. Mikrotiks vaktē, lai tā upstream DNS ir vienmēr sasniedzams. Jo savādāk arī tam iestāsies līdzīga problēma kā visām iekārtām pirmajā gadījumā. BET. Ja Mikrotiks proaktīvi arī nomaina sava upstream DNS IP, tad viss čill un ne ilgāk kā minūti pēc pihole nāves internets arkal ir glorī.
2022. gada 20. janvārī, plkst. 01:23
Nu ar stāšanos rindā laikam vairs nebūs tasinība. Vismaz kopš Win7 laikiem DNS pieprasījumi tiek sūtīti vienlaicīgi uz vairākiem serveriem un izmantota pirmā saņemtā atbilde. Arī citi svaigi "OSi" tā dara. Ideja ir jauka, bet vai tad vienkāršāk nebūtu uzlikt divus PiHole? DNS pēc sava dizaina ir augstas pieejamības risinājums - active-active, pat neprasa "kļūmjpārlēci". Bet Mikrotikam (vai īpaši izvirtušiem - Zabbixam) uzticēt uzrauga lomu un telegrafēt par viena PiCauruma atteici, pirms vēl tas, kopā ar otru PiCaurumu, ir ietekmējis mājiniekus? Bet nu ko es te rakstu, pats kurpnieks... :)
2022. gada 20. janvārī, plkst. 09:51
Interesanti. Jo vairāk tāpēc, ka man iepriekš setaps šādi kā reizi nestrādāja (192.168.1.5, 8.8.8.8, 1.1.1.1). Kā nomira pi, tā viss nomira. Moš jāpaeksperimentē vēl. Pastāv nenulles varbūtība, ka esmu overinženierējis :)
2022. gada 19. janvārī, plkst. 12:20
Mans mājas maršrutētājs ir Raspberry Pi 3 un, ja ir elektrība, problēmu praktiski nav. Izmantoju to, lai dinamiski izlīdzinātu plūsmu starp diviem dažādu pakalpojumu sniedzēju interneta pieslēgumiem. Ja tomēr kaut kas neiet, pastāv administratīvs risinājums — katrs mājinieks izmanto sava mobilā telefona USB vai WiFi tīklāju.
2022. gada 19. janvārī, plkst. 14:53
Neiesaku, 1.1.1.1 upstream, jo nesuportē ECS. Man bieži bija problēmas ar Youtube video ielādi, ar gigabit internetu reizēm pat uz 480p nometa kvalitāti. Pi-holā nomainīju upstram uz Quad9 (filtered, ECS, DNSSEC) un vairs nekādu problēmu.
2022. gada 19. janvārī, plkst. 14:58
Man ar 1.1.1.1 problēmu līdz šim nav bijis. Par ECS - pieļauju, ka man vienalga, jo tādas optimizācijas īsti ikdienā nenoder. Vismaz toč neemsu novērojis. Un gigabits man nespīd :)
2022. gada 20. janvārī, plkst. 08:14
Kā ar mikrotika DNS kešatmiņu? Ja visu proksē caur rūteri, un ir nepieciešamība tomēr kaut ko atbloķēt, tad jātīra saķešotais rūterī, nepietiks jau PIcaumurā atzīmēs kā "ok, lai iet caur"
2022. gada 20. janvārī, plkst. 09:50
Kešatmiņu var atslēgt, TTL norādot "0".
2022. gada 20. janvārī, plkst. 13:07
Kā tu savām ierīcēm iebaro, lai izmanto PiHole DNS? Mikrotik konfigā ar NAT rules ķert 53. portu īsti neder, jo skripts maina tikai DNS ierakstu.
2022. gada 20. janvārī, plkst. 13:42
Man visas ierīces mājās ir DHCP klienti. Dažām ierīcēm IP tiek piešķirta no tā paša DHCP servera statiski ("make static" funkcija klientu srakstā piesien izsniegto IP pie ierīces MAC adreses).
2022. gada 20. janvārī, plkst. 14:17
Man ir identiski. Es kaut kā biju iedomājies, ka ierīcēm kaut kā jāiebaro, lai lieto DNS, kas norādīts rūtera konfigā, jo sākumā pie PiHole rekvestiem bija tukšums. Paldies!
2022. gada 16. novembrī, plkst. 21:59
Vēl tikai mācos Mikrotiku hobija(mājas lietošanai) līmenī, nesodīt bargi. Pareizi saprotu, ka skriptu saturu iekopējot pie skriptiem, tā saturs pēc vienas palaišanas turpinās izpildīties automātiski, vai to tomēr jādara ar scheduleri? Kas tādā gadījumā notiks ar Telegram notifikācijām, nenāks katru reizi, kad scheduleris nostrādās? Visu sakonfigurējot, un manuāli palaižot "Run Script", smuki atnāk paziņojums, ka viss strādā no mana(Adguard) DNS.