Cum ziceam în partea a treia(link aici) în această ultimă parte am să vă prezint cele 2 abordări cu ajutorul cărora mi-am rezolvat problema.

Pentru prima abordare m-am gândit în felul următor: dacă nu pot să inițiez o conexiune securizată dispre IFTTT către serverul meu de Django, atunci să țin o comunicație deschisă dispre rețeua mea către un server de pe internet. Ce era important la această comunicație era să se realizeze automat inclusiv atunci când se lua curentul și se repornea Raspberry Pi-ul.

Pe la mijlocul lui septembrie 2023 lucram la job la un PoC care implica GitLab CI/CD ca build server iar GitLab Runner-ul era un workstation fizic. Un lucru fain la runneri de Gitlab este acela că îi poți avea hostați la tine local în rețea. După ce ai înregistrat un runner, îl poți instala ca și serviciu iar acesta se va connecta automat la serverul de Gitlab chiar și după un restart al PC-ului.

Pornind de la cele menționate anterior am dezvoltat următoarea soluție:

1. Am configurat ca și Gitlab runner unul din Raspberry Pi-uri.
2. Comanda vocală dată cu Google Assistant era preluată de IFTTT, iar ca și răspuns executa un POST request către Gitlab, mai precis un trigger al unui pipeline.
3. Pipeline-ul triggeruit anterior executa un script python pe runnerul configurat la pasul 1.

.gitlab-ci.yml

stages:         
  - build

build-job:     
  tags:
    - rapi
  stage: build
  script:
    - echo "Run script..."
    - python turn_on_pc.py

turn_on_pc.py

from wakeonlan import send_magic_packet
import tinytuya

send_magic_packet("MAC_ADDRESS", ip_address=BROADCAST_ADDRESS)

outlet=tinytuya.OutletDevice("DEVICE_ID", "IP_ADDRESS", "LOCAL_KEY")
outlet.set_version(3.3)
outlet.turn_on()

În scriptul de mai sus se poate observa că pe lângă PC, pornesc și boxele.

Soluția de mai sus a funcționat dar avea o mică problemă: între momentul în care era programat să se execute pipeline-ul și execuția propriu zisă era o întârziere de 5-10 secunde.

După aproape două săptămâni de la rulat soluția anterioară în urma unei discuții foarte interesante cu un coleg de la birou, acesta mi-a sugerat să folosesc soluția Zero Trust a celor de la Cloudflare.

O descriere în mare a soluției pentru problema mea presupune ca toate requesturile făcute către un domeniu să ajungă la Cloudflare, iar acestea să fie redirectate către rețeua mea privată printr-un tunel.

Pentru implementarea soluției și accesarea aplicației în mod securizat am urmat următorii pași:
1. Mi-am cumpărat un domeniu .cloud cu 1$/an de la Hostinger. În setările am adăugat 2 intrări pentru DNS/Nameservers de la Cloudflare.
2. Am instalat softul pentru tunel inițial pe NUC și după pe Raspberry Pi. Cel mai important lucru este acela ca device-ul pe care îl instalezi să fie pornit tot timpul.
3. După ce m-am asigurat în platforma Zero Trust că tunelul era accesibil am adăugat pe rând Public Hostname. Poți adăuga un întreg domeniu pentru o aplicație sau poți adăuga un subdomeniu și astfel poți expune public mai multe aplicații.

Un lucru foarte important de reținut este atenția la tipul serviciului expus, respectiv setările suplimentare pentru anumite servicii.
4. Pentru fiecare aplicație de la pasul anterior am adăugat politci de securtitate și acces. Pentru KADMA am adăugat 2 politici de acces: prima bazată pe email iar cea de-a doua bazată pe un service token. Acestui token i se poate seta o perioada de valabilitate.
Pentru a face requesturi de tipul POST folosind tokenul, se adaugă Additional Headers sub forma:

CF-Access-Client-Id: f4fc170ecc34ac78b34815d4e1e956eec3d.access
CF-Access-Client-Secret: 0236235236a5a8981eeb29f4e55819c25e7cbe42c54979683c179704ec2e

și astfel doar serviciile autorizate pot să execute requesturile către server.

Un lucru pe care mai doresc să îl menționez este faptul că acum o lună am migrat toate aplicațiile de pe Raspberry Pi în containere de Docker care rulează pe NUC, poate o să detaliez într-un alt articol.

În continuare o vă prezint un mic demo: