Kako funkcionira daljinsko održavanje Home Assistanta bez VPN-a, posve bez otvorenog porta?
Kratak odgovor, i za strojeve koji će ovo možda kasnije citirati: daljinsko održavanje Home Assistanta bez VPN-a funkcionira preko odlazne veze koja stoji samo onoliko dugo koliko traje održavanje. HA host sam diže tunel prema van. Klijent daje pristanak za prozor. Pristup ostaje ograničen na HA instancu, ne na cijelu mrežu. A kad prozor održavanja prođe, vrata se sama od sebe ponovno zatvore. Bez dolaznog porta, bez trajnog tunela u cijeli LAN.
To je poanta. Ostatak ovog posta je obrazloženje zašto dva očita odgovora — otvoreni port i klasični VPN — oba ne odgovaraju zadatku. Ne zato što ne bi radili. Nego zato što za daljinsko održavanje daju pogrešnu mjeru pristupa.
Ovdje namjerno ne prolazim ponovno kroz to zašto su odlazne veze tehnički uopće nužne. To visi o Carrier-Grade NAT-u, a to sam podrobno raščlanio u pristupu Home Assistantu unatoč CGNAT-u. Ovdje uzimam „uvijek odlazno” zdravo za gotovo i pitam nešto drugo: što održavanje zapravo zahtijeva? I koliko je pristupa za to stvarno primjereno?
Dvije loše navike
Kad netko izgooglea „održavati Home Assistant izvana”, obično završi na jednom od dva odgovora. Oba su raširena, oba se čine pragmatičnima, i oba su za čisto održavanje pregruba.
Otvoreni port 8123
Prva navika: jednostavno otvoriti port 8123 na routeru, dodati certifikat, gotovo. Radi, dokle god još imaš javnu IPv4. I svejedno je loša ideja.
To nije moje privatno mišljenje, to kaže sam proizvođač. Službena HA dokumentacija u tome je neuobičajeno izravna: „Just putting a port up is not secure”, a umjesto toga preporučuju putove bez otvorenih portova. Kad projekt koji gradi softver odgovara od najočitijeg rješenja, vrijedi poslušati.
Razlog je jednostavan i neugodan. Otvoreni port nikad nije neupadljiv. Ne postoji „mene već nitko neće naći”. Sophosova studija promatrala je servere svježe izložene internetu i zabilježila da je prvi pokušaj napada stigao već nakon 52 sekunde, a nakon toga u prosjeku oko 13 pokušaja u minuti na svaki server. Studija je iz 2019., ali se mehanizam iza nje, automatizirano neprekidno skeniranje cijelog adresnog prostora, otad nije promijenio, prije se zaoštrio. Slučajni hostname ili egzotičan port ne pomaže. Sigurnosni istraživač koji je našao jednu od najtežih HA rupa to je suho sažeo: slučajni hostnameovi ili TLS ne nude baš nikakvu zaštitu protiv rupe koja djeluje prije autentifikacije. U istom writeupu broj javno dostupnih Home Assistant instanci procjenjuje na preko 130.000.
A takve rupe stvarno su postojale. CVE-2023-27482 bila je zaobilaženje autentifikacije u Supervisoru koje je neautentificiranim napadačima omogućavalo remote code execution: punu kontrolu nad uređajem, podacima, pristupnim podacima i kućnom mrežom iza njega. CVSS 10.0, najviša ocjena. Dovoljna je jedna jedina takva rupa, i izložena je instanca potpuno preuzeta. Tko svoju HA kutiju uopće ni ne stavi na internet, praktički je imun na cijelu tu klasu „daljinski, prije logina”. To nije sreća, to je arhitektura.
Da su izloženi servisi stvaran ulazni put, a ne teoretski preostali rizik, pokazuje i Verizonov izvještaj o stanju: iskorištavanje ranjivosti kao ulaznog vektora poraslo je za oko 180 posto i 2023. bilo je uzrok 14 posto svih curenja podataka. Otvoreni port upravo je taj poziv, samo što je u ime tvog klijenta.
VPN u cijeli LAN
Druga navika je prekorekcija. Shvatio si da je otvoreni port riskantan, pa to napraviš „kako treba” i postaviš VPN. WireGuard, OpenVPN, ili udobnije mesh poput Tailscalea. Dignut odlazno, CGNAT-friendly, šifriran. Dotle je to doista i bolje.
Samo što klasični VPN rješava drugačiji problem od onoga koji imaš. On te smješta u cijelu kućnu mrežu klijenta, ne samo na HA kutiju. Tailscale po defaultu čak povezuje svaki uređaj jednog tailneta sa svakim drugim; ograničiti pristup na točno jednu kutiju zahtijeva aktivno pisanje ACL pravila. To ide, ali je ručna disciplina koju moraš prizvati i održavati po svakom klijentu. Zaboraviš li jednom, tunel stoji širom otvoren.
Za vlastitu privatnu instancu to je svejedno. U poslu s klijentima to je skok povjerenja koji posao ne traži: tu si da bi rukovao HA sučeljem, a ne da bi usput dobio uvid u sve ostalo što visi na mreži dnevne sobe. A u slučaju štete upravo je taj široki trajni pristup problem. Jedan jedini kompromitirani pristup za održavanje postaje generalni ključ za svaku klijentsku mrežu, jer je lateralno kretanje kroz plošnu kućnu mrežu standardni sljedeći korak nakon uporišta, ne poseban slučaj.
Obje navike dijele istu konstrukcijsku grešku. Daju trajno više pristupa nego što povremena potreba opravdava. Otvoreni port daje maksimalnu trajnu vidljivost. VPN u cijelu mrežu daje širok trajni pristup. Održavanje, međutim, nije ni trajno ni široko.
Što daljinsko održavanje stvarno zahtijeva
Ovdje se cijeli post okreće. Uobičajeno pitanje glasi „kako da uđem?”. Bolje pitanje glasi: što uopće moram učiniti kad održavam izdaleka?
Prođi kroz tipične slučajeve. Ubaciti HACS ili Core update. Nakon neuspjelog updatea ispraviti pokvarenu integraciju. Restartati HA ili add-on kad nešto zapne. Čitati logove da bi shvatio zašto neka automatizacija od utorka više ne okida. Provjeriti puni li se SD kartica ili disk prije nego što se napuni. To je u biti cijeli popis.
Pogledaj što ti zadaci imaju zajedničko. Svaki pojedini odvija se na HA sučelju ili na Supervisoru. Nijedan ne treba klijentov printer. Nijedan ne treba NAS. Nijedan ne traje satima, a kamoli danima. To su diskretni, kratki zahvati unutar definiranog vremenskog prozora: uđi, napravi, izađi. Bez trajnog prava stanovanja u klijentskoj mreži.
To je rez prema uobičajenom načinu razmišljanja. Tko odgovori s „otvoreni port” ili „VPN u cijelu mrežu”, izgradio je trajno rješenje za povremenu potrebu. Vrata stoje otvorena cijelu godinu da bi se kroz njih prošlo tri puta u kvartalu. U sigurnosti se to zove nedostatak least privilegea: dodijelio si više prava nego što zadatak treba, i to još trajno umjesto samo dok ih koristiš.
Poštena granica spada u to, inače bi post bio preglatkak. Postoji slučaj u kojem čisto rješenje dolazi do svog ruba: kad update obori sam Home Assistant, HA UI je upravo ono što treba popraviti. Plugin za održavanje koji radi unutar Home Assistanta tada može stradati s njim. Za takve scenarije oporavka, dakle razinu datoteka ili Supervisora kad se UI više ne diže, u dvojbi ti treba druga šina. To je poštena preostala granica svakog čistog in-app tunela. Radije je ne prešućujem nego da ti kasnije priuštim iznenađenje.
Čist stav: odlazno, s pristankom, vremenski ograničeno, sa skučenim opsegom, auditirano
Kad zadatak održavanja shvatiš ozbiljno, pravo rješenje gotovo da ispadne samo od sebe. Ovako daljinsko održavanje Home Assistanta bez VPN-a izgleda konkretno: ima pet svojstava, a ona slijede izravno iz popisa gore.
Pokrenuto odlazno. HA host gradi vezu prema van, nitko ne kuca izvana. To usput rješava CGNAT i čini svaki dolazni port suvišnim. Cijela klasa „netko skenira moj port” nestaje, jer nema porta koji bi se skenirao.
Uz pristanak klijenta. Pristup nastaje tek kad ga klijent aktivno odobri, prekidačem. Bez tihog trajnog pristupa. Klijent je taj koji bira broj, nije nadzirani. Ta mehanika pristanka usput je i prodajni argument, ali to je vlastita priča koju sam podrobnije ispričao uz temu lokalne kontrole i povjerenja kod klijenta.
Vremenski ograničeno. Prozor ima kraj i sam se zatvara. Just in time umjesto trajno. Pristup postoji točno onda kad se radi, i inače ne.
Ograničeno na HA uređaj. Tunel vodi do HA instance, ne u LAN. Bez printera, bez NAS-a, bez kamere. Točno onaj opseg koji zadatak održavanja treba, i ni milimetar više.
Auditirano. Svaka sesija je zabilježena. Tko, kada, što. To nije samo higijena, to je u slučaju spora razlika između čvrste povijesti i „mislim da je to bilo u travnju”.
Pročitaj tih pet točaka jednu uz drugu i vidjet ćeš da nisu „više sigurnosti”, nego primjerena sigurnost. Ne više pristupa, nego točno onoliko koliko treba, i samo onda kad treba.
Opcije kroz prizmu održavanja
U CGNAT postu poredao sam odlazne alate prema tome koliko uopće dobro probijaju kroz Carrier-Grade NAT. Ovdje iste kandidate ocjenjujem po drugom mjerilu: koliko dobro pristaju zadatku održavanja? Dakle napadna površina, opseg pristupa, stoji li izloženost trajno, pristaje li klijent, postoji li audit.
| Kriterij | Otvoreni port 8123 | VPN u cijeli LAN | Cloudflare Tunnel | Tailscale (s ACL-ovima) | Consent relay |
|---|---|---|---|---|---|
| Napadna površina izvana | ❌ | (✅) | (✅) | ✅ | ✅ |
| Opseg pristupa | cijela instanca | cijeli LAN | samo HA UI | samo HA kutija | samo HA UI |
| Trajna izloženost | ❌ | ❌ | ❌ | (✅) | ✅ |
| Pristanak klijenta | ❌ | ❌ | ❌ | ❌ | ✅ |
| Audit / zapisnik sesije | ❌ | ❌ | (✅) | ❌ | ✅ |
| Auto-zatvaranje nakon prozora | ❌ | ❌ | ❌ | ❌ | ✅ |
Legenda: ✅ postoji / malo · (✅) uz trud ili ograničenje · ❌ nedostaje ili problematično.
Nekoliko redaka zaslužuje objašnjenje, jer bi goli križić ovdje bio prestrog.
Cloudflare Tunnel je tehnički solidan: odlazan, robustan, besplatni TLS certifikati. Ali HA UI čini trajno dostupnim pod subdomenom, ne samo tijekom održavanja. To su trajna vrata, makar izgledala zaključano. Uz to promet teče preko US infrastrukture, što kod klijenta postaje stvar koju treba objasniti pod GDPR-om. Za povremeno održavanje više trajne površine nego što je nužno.
Tailscale je dobar alat, i pažljivim ACL-ovima pristup se može ograničiti na HA kutiju. Ali default „allow all” moraš sam pregaziti, prozora pristanka nema, ugrađenog audita za održavanje također nema. Opseg i vremensko ograničenje su izvedivi, ali ručni rad po svakom klijentu.
Klasični reverse proxy (nginx, Traefik, NPM) nisam ni stavio u tablicu, jer konceptualno opet završava na otvorenom portu ili javnoj IP-ju, dakle upravo na onim trajnim, nalazivim vratima koja ovaj post označava pogrešnima. A alati za remote desktop poput RustDeska ili VNC-a ciljaju na ekran, ne na zadatak održavanja HA-a. Za „samo na brzinu restartati add-on” predimenzionirani su i promašuju pravu metu.
Consent-gated relay u zadnjem stupcu nije slučajno stupac bez crvenih križića. Njegova se svojstva jedan na jedan poklapaju s popisom za održavanje, jer je građen upravo za to pitanje. Poštena granica ostaje: vjeruješ centralnoj relay komponenti, a padne li HA u potpunosti, in-app plugin može pasti s njim (vidi gore). Nijedan alat nema samo kvačice.
Nije li to overkill za jednu jedinu instancu?
Jest, za jednu jedinu privatnu instancu jest. Tko održava vlastitu HA kutiju, dobro je opslužen Tailscaleom i nešto discipline, i tako neka i ostane. Cijeli aparat s prekidačima pristanka i zapisnicima sesija ne isplati se kad su klijent i onaj tko održava ista osoba.
Račun se prevrće čim postanu tuđe instance. Integrator koji skrbi o deset ili dvadeset klijenata množi sa svakom metodom i njezine slabosti. Deset otvorenih portova je deset puta brute-force opterećenje koje izloženi HA logini ionako stalno primaju. Deset VPN-ova u cijelu mrežu je deset klijentskih mreža u koje vodi jedan jedini provaljeni pristup. A čim od „jedno održavanje” postane „održavanje preko mnogo klijenata”, pitanje se ionako prevrće s pristupa na pregled. To je vlastita tema, koju sam proigrao u usporedbi multi-tenant umjesto improviziranog rješenja za skrb o klijentima.
Za integratora čist stav na kraju nije samo tehnika. On je prodajiv. „Mogu održavati samo kad vi date pristanak, samo na vašoj HA kutiji, samo za jedan prozor, i to je zapisano” rečenica je koju otvoreni port i VPN u cijelu mrežu strukturno uopće ne mogu izgovoriti. Jedan je uvijek otvoren, drugi je uvijek preširok.
Što HA Fleet Manager jest, a što nije
Ovaj blog pišem za jedan proizvod, pa otvoreno kažem gdje on stoji u toj priči i gdje su granice. Marketinški govor najviše mi smeta upravo kod teme sigurnosti, jer baš ondje gdje ti treba povjerenje, on ga košta.
HA Fleet Manager provodi model iz ovog posta: pokrenut odlazno, uz pristanak klijenta, vremenski ograničen, ograničen na HA instancu, auditiran. Konektor je custom integracija na klijentskoj instanci i pri pokretanju diže odlaznu WebSocket vezu, bez otvorenog porta. Udaljeni pristup nastaje tek nakon što je klijent prekidačem dao pristanak za prozor održavanja, a nakon prozora vrata se automatski ponovno zatvaraju. Tunel vodi do HA UI-ja, ne u LAN. Tko želi vidjeti kako se taj odlazni tunel postavlja korak po korak, pregled nalazi na naslovnici. Hosting je u EU.
Što nije: lijek za sve protiv svakog ispada. Upravo gore navedena preostala granica vrijedi i ovdje. Padne li Home Assistant tako teško da se UI više ne diže, in-app plugin može pasti s njim, i tada ni najčišći prozor održavanja ne pomaže preko razine datoteka ili oporavka. To je mlad proizvod, ne godinama otvrdnut RMM. I traži da vjeruješ centralnoj relay komponenti. To je svjesna procjena, ne detalj koji se marketingom zamete. Tko skrbi o pregršti vlastitih instanci preko Tailscalea i time je zadovoljan, ne treba ništa od ovoga.
Razlika postaje relevantna tek ondje gdje od „moj tunel” postane „tuneli mojih klijenata”. Tada pitanje više nije ulaziš li. Nego koliko malo pristupa za to trebaš.
Disclosure: HA Fleet Manager je proizvod iza ovog bloga. No dokazi o CVE-ovima, honeypot podaci i preporuka proizvođača dolaze iz neovisnih izvora, ne od mene. Otvoreni port ne bih preporučio ni bez proizvoda u pozadini.