Hardening d'homelab amb VLAN: guia completa de seguretat a casa

Informatec Digital » Recursos » Hardening d'homelab amb VLAN: guia completa de seguretat a casa

Si tens un homelab amb un grapat de atuells (NAS, miniPCs, Raspberry, càmeres, domòtica, etc.) i tot està connectat al mateix rang de xarxa, casa teva és, a nivell digital, un camp obert per a moviments laterals i atacs ximples . No cal ser una gran empresa perquè t'escanegin ports, et rebenten una contrasenya fluixa o un atuell IoT quedi exposat a una fallada de seguretat.

La idea d'aquest article és que puguis muntar, pas a pas i amb cap, una xarxa domèstica segmentada amb VLANs, tallafocs i bones pràctiques de hardening, perquè els teus serveis casolans funcionin igual de bé, però amb molt més control, menys ensurts i una superfície d'atac força més petita . Combinarem el millor de diversos enfocaments: pfSense/OPNsense, Unifi, Zero Trust (Tailscale, Cloudflare Tunnel) , Proxmox, Kubernetes lleuger, Pi-hole, Home Assistant, etc.

Per què el teu homelab necessita segmentació i hardening ja

En una xarxa “plana” clàssica, tipus 192.168.1.0/24 amb tot ficat allà, qualsevol dispositiu pot veure i, en molts casos, parlar amb tots els altres. Si una bombeta, una TV o un endoll “llest” es veu compromès, l'atacant pot intentar saltar al teu NAS , al teu PC personal, a l'hypervisor de Proxmox o al servidor on guardes còpies de seguretat . No cal un atac gaire sofisticat; n'hi ha prou amb una fallada de firmware que ningú pegat.

A més, barrejar-ho tot a la mateixa xarxa fa que el trànsit de descobriment (broadcast, multicast, mDNS, etc.) es descontroli. Això genera soroll, complica el diagnòstic de problemes i, a sobre, dóna massa informació sobre què tens, quins ports uses i quins serveis corren a la teva LAN . La segmentació amb VLANs ataca justament aquest problema: separar dispositius per funció i nivell de confiança.

Pensa en el teu homelab com un petit centre de dades: tens serveis crítics (DNS, VPN, emmagatzematge), serveis públics (reverse proxy, aplicacions exposades per túnels), dispositius poc fiables (IoT, convidats, consoles dels nens) i el teu equip personal. Cada grup hauria d'estar al seu “carril” i només poder parlar amb els altres mitjançant regles de tallafocs molt concretes i justificades.

VLANs a l'homelab: conceptes que sí utilitzaràs

Una VLAN no és màgia: és simplement un domini de broadcast separat a la capa 2 . Normalment s'hi associa 1 VLAN = 1 subxarxa IP, però en realitat són conceptes diferents. La VLAN defineix com se separen els frames Ethernet; la subxarxa, com s'encamina el trànsit a la capa 3. L'important per a tu és que els dispositius d'una VLAN no veuen els broadcasts d'una altra, i només es comuniquen entre si intervé un router o firewall.

La separació s'aconsegueix amb etiquetes 802.1Q (VID, d'1 a 4095) que els switches insereixen als paquets. Un port pot treballar de dues formes bàsiques: com a port d'accés (access), on el trànsit surt/entra sense etiquetar i tot pertany a una única VLAN, o com a port troncal (trunk), on un mateix cable transporta diverses VLAN etiquetades alhora cap a un router, un altre switch, un AP o un hypervisor.

El famós PVID o VLAN nativa defineix quin VLAN s'assigna al trànsit que entra sense etiqueta a un port. Cada fabricant ho ensenya diferent a la interfície web (PVID, VLAN d'accés, Native VLAN…), però la idea és la mateixa: el switch decideix a quin VLAN pertany un frame sense tag i, en treure'l per un port d'accés, normalment treu l'etiqueta perquè el dispositiu final vegi “Ethernet normal” i no hagi de saber res de VLAN.

En un homelab típic tindràs, almenys, un enllaç troncal entre el teu firewall/router (pfSense, OPNsense, Unifi, OpenWrt…) i el teu switch principal, i des d'aquí ports d'accés per a PCs, TVs, consoles, càmeres, etc. A més, si uses Proxmox o un host de virtualització, és molt habitual configurar un enllaç troncal cap a l'hypervisor i deixar que les VMs o contenidors etiquetin el seu trànsit directament, usant bridges tipus vmbr0 + VLAN tags.

Disseny pràctic de VLANs per a un homelab modern

Abans d'obrir el panell del switch com un posseït, agafa paper (o un editor de text) i defineix quines xarxes vols i per què. Un esquema raonable, que agrupa el que es veu en moltes configuracions reals, podria ser una cosa així, adaptant rangs IP i números de VLAN al teu gust:

• Xarxa “Default” o Domèstica: on viuen els dispositius personals de la família (mòbils, portàtils, sobretaules). És la xarxa “de confiança” i normalment la que tindrà un permís una mica més lax per sortir a Internet.
• VLAN Convidats: pensada per a visites. Només Internet sense accés a la resta de rangs privats, amb aïllament entre clients si l'AP ho permet.
• VLAN IoT: per a bombetes, endolls, altaveus, Smart TV, termòstats, robots aspirador, etc. Trànsit molt limitat cap a dins i controlat cap a fora.
• VLAN Homelab / Serveis: on resideixen els teus VMs, contenidors, NAS, Home Assistant, bases de dades, reverse proxies, etc. Sol comunicar-se amb IoT i Default, però de manera molt controlada.
• VLAN “Secure” o VPN: segment on tot el trànsit cap a Internet surt per un túnel VPN permanent (per exemple, Proton VPN o similar), sense que el dispositiu hagi d'instal·lar un client.
• DMZ: opcional però molt recomanable per a serveis potencialment exposats (reverse proxy, servidors web, VPNs, etc.), tractant-los com si fossin “semi-confiables” i sense pont directe a la resta de xarxes internes.

Una manera clara d'organitzar adreces privades és fer servir alguna cosa com 10.10.X.0/24 per a cada VLAN i mantenir un full amb els rangs, noms i propòsits . Per exemple: 10.10.10.0/24 Default, 10.10.20.0/24 IoT, 10.10.30.0/24 Convidats, 10.10.40.0/24 Homelab, 10.10.50.0/24 Secure. Amb això, les teves regles de tallafocs i les reserves DHCP seran molt més fàcils de mantenir en el temps.

Si utilitzeu Unifi o solucions similars, és habitual mapejar cada VLAN a una xarxa al controlador i, alhora, vincular cada xarxa a un SSID concret. Així, en triar el WiFi “Casa”, “IoT”, “Convidats” o “VPN”, automàticament el dispositiu cau a la VLAN correcta i hereta les polítiques de tallafocs i accés que hagis definit per a aquest segment.

Triar maquinari i programari per manejar VLANs i routing

Pel que fa al switch, amb quin suport 802.1Q i et deixi configurar VLAN tagging, trunks i PVIDs vas servit. La diferència grossa és si l'equip només fa switching capa 2, o si fa també routing capa 3 a velocitat de línia . Molts switches “econòmics” poden etiquetar i reenviar frames a gran velocitat, però quan els demanes que trenquin trànsit entre VLANs el deriven a la CPU i es desplomen a uns pocs centenars de Mbps.

Si vols simplificar, el més habitual en un homelab és deixar el routing entre VLANs al ​​firewall/router principal (pfSense, OPNsense, Unifi Security Gateway, Dream Machine, OpenWrt en un router decent, etc.) i utilitzar els switches només per a la capa 2. Si el teu trànsit intern és molt backups grossos), potser et compensi un switch L3 amb offload de routing per maquinari , però per a la majoria de cases no és imprescindible.

Al plànol de programari, hi ha tres grans camins:

• openwrt en routers modestos per començar, amb capacitat d'etiquetar ports, crear diverses xarxes i aplicar regles bàsiques de tallafocs.
• pfSense o OPNsense en una màquina x86 (bare metall o VM) si vols regles avançades, GeoIP, IPS/IDS, VPNs potents, alta disponibilitat amb CARP, etc.
• unificar (Dream Machine, Dream Router, etc.) si preferiu un entorn integrat amb APs i switches gestionats des del mateix controlador, amb una corba d'aprenentatge una mica més amable.

Per a l'hypervisor, Proxmox brilla precisament en xarxes complexes: només cal crear bridges associats a les NIC físiques (per exemple vmbr0 sobre enp1s0), marcar aquest port del switch com a troncal i deixar que cada VM o contenidor etiqueti amb el VLAN ID que necessiti. Això permet que un mateix servidor formi part de diverses VLANs alhora i actuï, per exemple, com a host de serveis d'homelab accessibles des de Default i IoT sense muntar invents rars als switches.

De la teoria a la pràctica: creació i prova de VLANs

Un cop decidit el disseny, al switch defineix cada VLAN amb el seu VID i un nom descriptiu. Després marques els ports que connecten amb el router/firewall, amb altres switches i amb Proxmox com a troncals, permetent les VLANs que vulguis transportar. En aquests ports, és millor evitar utilitzar VLAN nativa diferent a cada extrem per no tenir fuites de trànsit sense etiquetar o comportaments rars.

Els ports als quals connectaràs dispositius “tontos” (TV, consola, PC sense suport de VLANs, càmeres) els deixes com a ports d'accés: una sola VLAN sense etiquetar, amb el PVID corresponent. Així, aquest equip sempre caurà a la xarxa que tu hagis decidit, sense que es pugui “escapar” a una altra per error de configuració.

Al firewall/router, creeu una interfície lògica per cada tag que travessi la targeta de xarxa connectada al switch. pfSense i OPNsense, per exemple, deixen crear interfícies VLAN sobre una NIC física, ia cada interfície li assignes IP, rang DHCP, DNS, descripció i, el més important, les regles de tallafocs independents . Aquestes normes per interfície són la clau de l'aïllament.

Quan el tinguis configurat, toca provar: endolla un portàtil a un port d'accés d'IoT, mira quin IP rep, comprova quin gateway i DNS veu, i verifica que no pot fer ping a la subxarxa Default ni a la de Homelab, però que sí que resol dominis públics i surt a Internet (si és el que vols). Repeteix exercicis similars per a Convidats, Homelab i Secure fins que t'asseguris que cada xarxa es comporta com a pretenies.

Firewall i regles per tallar el moviment lateral

L'enfocament de base que millor funciona és el de denegar per defecte i només permetre el necessari . És a dir, a cada VLAN crees una regla inicial que permet trànsit “establert/relacionat” (per deixar passar respostes a connexions iniciades des de dins) i, després, negues el trànsit cap a altres xarxes privades (tipus RFC1918) excepte les excepcions justificades.

Una tècnica còmoda és crear un grup d'IPs que contingui tots els blocs privats (per exemple 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) i referenciar-lo a les regles. Així, una regla que bloquegi “IoT → PrivateNetworks” curta d'un cop de ploma que les bombetes i els atuells intentin parlar amb la teva NAS o el teu portàtil, deixant només obert el camí cap a Internet i, si ho necessites, cap a algun servei molt concret de l'homelab.

A la xarxa Default pots permetre “LAN a qualsevol lloc” (internet + altres VLANs), però és bona idea seguir limitant què pot accedir a la DMZ oa certs servidors sensibles. A Convidats, en canvi, el més normal és bloquejar tot accés a rangs privats i mantenir únicament sortida a Internet. Si l'AP suporta aïllament entre clients, activa-ho perquè els mòbils de les teves visites ni tan sols es vegin entre ells.

Per a la relació entre Homelab i IoT, un patró típic és permetre que un únic host (per exemple, el contenidor o VM de Home Assistant) pugui arribar a certs dispositius IoT a ports específics (port d'API, port de control), però no al revés. Això s'implementa amb una regla tipus “HomelabHost → IP_IoT:port” permesa i, a continuació, un bloqueig general d'IoT cap a Homelab i Default excepte trànsit establert.

Fer que multicast, mDNS i companyia no siguin un infern

Quan comences a separar xarxes, t'adones que coses com AirPlay, Chromecast o algunes impressores “desapareixen”. No és un bug: molts mecanismes de descobriment usen broadcast o multicast i, per disseny, no salten entre VLANs. Perquè segueixin funcionant, necessites ser selectiu amb quin trànsit de descobriment deixes passar.

El més habitual és activar IGMP Snooping als switches per limitar el multicast només als ports on hi hagi clients interessats. Després, al router/controlador, habilites un relay de mDNS/Bonjour o un servei equivalent, dient explícitament entre quins VLANs vols que es reenviïn anuncis (per exemple, entre Default i IoT, o entre Default i Homelab).

A Unifi, a més, pot cal crear regles LAN-IN que permetin el port i el tipus de trànsit de mDNS, o ajustar perfils de multicast per a cada SSID. Convé anar amb calma: habilita el relay només entre els segments que realment necessiten veure's i comprova que no es cola més informació del compte entre xarxes que pretenies aïllar.

Hi ha dispositius, com Sonos, que es porten regular amb les VLANs i poden donar molts mals de cap encara que tècnicament hi hagi relays configurats. Molta gent acaba deixant-los a la xarxa Default (o en una VLAN específica de multimèdia) i acceptant que aquesta part no estarà tan segmentada a canvi que tot funcioni sense barallar-se amb el microprogramari del fabricant.

Gestió segura: MFA, SSH amb claus i Zero Trust

El teu tallafocs, els hosts Proxmox, els NAS i els serveis d'administració són “les claus del regne”. No val deixar un usuari root amb una contrasenya simple accessible des de qualsevol lloc. El que és sensat és crear un compte d'administració específica per al panell web del firewall, deshabilitar l'accés directe de root i activar sempre doble factor (TOTP, per exemple, a OPNsense).

A més, és molt bona idea limitar laccés a aquestes consoles de gestió només a una IP o subxarxa molt concreta dins de la VLAN de dispositius de confiança (per exemple, a la teva sobretaula o portàtil principal). D'aquesta manera, si algú aconsegueix entrar en una altra xarxa o comprometre un atuell IoT, no tindrà ni el tauler del tallafocs ni la interfície d'administració de l'hypervisor a tret.

Per a l'accés per SSH a servidors i VMs, l'ideal és desactivar completament l'autenticació per contrasenya i utilitzar només claus públiques . Pots anar més enllà i ficar un segon factor amb solucions tipus Duo: encara que algú robi la teva clau privada, l'intent de login genera una aprovació al teu mòbil i, si no l'autoritzes, la connexió es rebutja.

Amb vista a l'accés remot, la consigna és clara: deixar d'obrir ports directes (80, 443, 22…) al router. En el seu lloc, recolza't en solucions Zero Trust com Tailscale (VPN mesh recolzada a WireGuard), Cloudflare Tunnel o Twingate. Aquestes eines permeten exposar serveis interns de forma autenticada i xifrada sense haver de publicar la teva IP o els teus ports a Internet . Les teves aplicacions web, panells i SSH passen a estar accessibles només després d'autenticació prèvia i polítiques d'accés fines.

Endurir contenidors, sistemes i serveis

Els contenidors donen una falsa sensació de seguretat: estan aïllats, sí, però si corres tot de manera privilegiada, compartint volums d'escriptura per tot arreu i amb imatges sense manteniment, acabes igual d'exposat que amb serveis instal·lats directament al host. La base és usar imatges oficials o molt reputades , actualitzar amb regularitat i evitar el flag privileged excepte casos molt estudiats.

Sempre que puguis, munta volums en mode lectura per a dades estàtiques, separa configuracions de dades i limita les capacitats del contenidor a allò imprescindible. Comproveu els permisos dels sockets Docker i no exposeu panells sensibles com Portainer directament a Internet; col·loca'ls darrere d'un reverse proxy segur, amb autenticació addicional, o protegeix-los sota Tailscale / Cloudflare Tunnel.

Als sistemes base (Raspberry, miniPCs, VMs Linux) aplica la higiene mínima: canviar contrasenyes per defecte, activar actualitzacions regulars, deshabilitar serveis que no facis servir, configurar UFW o firewall equivalent amb política de denegar per defecte i obrir només el que calgui . Per a serveis molt atacats com SSH, un Fail2Ban o eines modernes tipus CrowdSec ajuden a bloquejar intents de força bruta.

Pel que fa al xifratge de comunicacions, ja no té sentit servir res a HTTP pla, ni tan sols dins de la LAN. Reverse proxies com Caddy, Nginx Proxy Manager o Traefik faciliten l'ús de certificats TLS (Let's Encrypt, etc.) i permeten afegir una capa extra d'autenticació, rate limiting, capçaleres de seguretat i altres, tant per a trànsit intern com per al que passi per túnels Zero Trust.

DNS, Pi-hole i bloqueig de “llistes negres” de DoH

Un punt clau per a la privadesa i el control de la teva xarxa és gestionar tu mateix el DNS. Pi-hole (o AdGuard Home) desplegat de forma redundant et permet bloquejar publicitat, telemetria i dominis sospitosos a nivell de xarxa, sense haver de configurar extensions de navegador a tots els dispositius. Això sí, necessites muntar la infraestructura perquè sigui difícil de tombar i difícil de saltar-se.

Pel que fa al “hardening” DNS, la idea és que tots els dispositius consultin exclusivament als teus servidors Pi-hole i que no puguin anar-se'n alegrement a 1.1.1.1, 8.8.8.8 oa adreces de DNS-over-HTTPS públiques. Per als qui s'entesten a ignorar el DNS de DHCP, es poden crear grups d'IP que continguin les adreces dels grans proveïdors de DNS i DoH públics (Cloudflare, Google, Quad9, etc.) i escriure regles de tallafocs que deixin sortir peticions DNS només si vénen dels teus Pi-hole i les bloquegin per a la resta.

A la pràctica, se solen definir perfils de grup tipus “Servidors Pi-hole” i ports “DNS” i “TLS-DoH”. Després s'afegeixen regles de sortida que permeten a Pi-hole parlar amb Internet en aquests ports, i just a sota regles que descarten qualsevol intent d'usar aquests mateixos ports des d'altres IP de la LAN. Amb això, qui intenti fer servir DNS propis es quedarà sense resolució i “aprendrà” a respectar la teva configuració.

Perquè Pi-hole sigui resilient, és bona idea allotjar les instàncies en dispositius diferents (per exemple, un contenidor a NAS, un altre a Proxmox, un altre en una Raspi amb SSD) i configurar DHCP per lliurar diverses IP de DNS als clients. Així, la caiguda d'un node no et deixa sense Internet i el servei continua funcionant mentre investigues què ha passat.

Zero Trust i accessos remots amb Cloudflare Tunnel i Tailscale

En lloc d'obrir ponts directes a casa teva, pots jugar amb un combinat molt potent: Cloudflare Zero Trust per exposar serveis web seleccionats (amb identitats, polítiques i auditoria) i Tailscale per accedir per VPN mesh a recursos interns com si estiguessis a la LAN, però sense tocar el NAT del router.

Cloudflare Tunnel (amb el client cloudflared corrent com a contenidor o servei) crea túnels sortints des de la teva xarxa cap a la infraestructura de Cloudflare. A partir d'aquí, associes un subdomini a aquest túnel i apuntes trànsit HTTPS cap a un o més serveis del teu homelab. Ningú no veu la teva IP domèstica ni els teus ports; veuen només el domini protegit per les capes de Cloudflare, on pots exigir login, 2FA, filtres geogràfics i altres lindezas.

Per a accés tipus “VPN tradicional” a tota la xarxa oa segments concrets, Tailscale és una meravella. S'instal·la amb un simple script, registra cada dispositiu al teu tailnet i genera una xarxa privada basada en WireGuard, amb ACLs per decidir quin usuari pot arribar a quin IP i port. D'aquesta manera, podeu limitar, per exemple, que només els vostres comptes personals accedeixin a 192.168.1.10:22 (l'hypervisor) oa 10.10.40.100:3000 (la vostra eina de CI).

Si vols anar un pas més, pots descriure tota la configuració de Zero Trust a Terraform utilitzant el proveïdor de Cloudflare. Així mantens la teva política com a codi, fas canvis de forma reproduïble i pots versionar-lo a Git, com si fos un altre projecte d'infra més. És una forma molt professional de tractar el teu homelab, encara que estigui en un armari del passadís.

Cablejat, LAGs i problemes típics de rendiment

El hardening lògic no serveix de gaire si la teva xarxa física és un acudit. Reaprofitar antigues preses RJ11 i cable vell pot ser una solució temporal, però és habitual que amb càrregues altes apareguin talls, errors de CRC o caigudes de velocitat en negociar. Sempre que tinguis oportunitat (obra, reforma, canvi de mobles), planteja't llençar cablejat CAT6 o CAT7 de qualitat i utilitzar patch panells amb keystones decents.

Per interconnectar cambres o armaris on tingueu diversos switches, l'enllaç troncal sol ser un coll d'ampolla. Si veieu que el trànsit entre zones se satura, podeu pensar en agrupar diversos enllaços físics en un LAG (link aggregation), sempre que els switches ho suportin. Així augmentes l'amplada de banda disponible i tens una mica més de resiliència davant de la caiguda d'un cable.

Documentar físicament quin port va on, quin VID s'usa a cada tram i com estan configurades les natives t'estalvia hores en el futur. Etiqueta cables, anota ports i mantingues-lo sincronitzat amb el teu diagrama lògic de VLANs. Una part enorme dels “misteris” de xarxa acaben sent un port mal etiquetat o un PVID incorrecte.

Quan alguna cosa vagi estranya (latències boges, TTL expirat, rutes que es repeteixen), tira eines bàsiques: traceroute des de diferents punts (client, router, modem), comptadors d'errors en interfícies, captures de paquets al tallafoc i, si el teu switch ho permet, un mirror port per veure què etiquetes per solucionar problemes de connexió.

Homelab com a laboratori: Proxmox, Kubernetes lleuger i serveis clau

Un cop tens la base de xarxa i seguretat assentada, l'homelab es converteix en un camp de proves brutal per practicar coses molt properes a entorns de producció: clusters amb Proxmox, Kubernetes lleuger tipus k3s, NFS des de NAS com a emmagatzematge compartit, backups, alta disponibilitat, etc.

Proxmox et permet orquestrar VMs i contenidors amb una interfície web senzilla, clustering nadiu, snapshots i backups integrats. Pots muntar un NFS des del teu NAS i utilitzar-lo com a emmagatzematge compartit de discos virtuals, còpies de seguretat o isos. Tot i que la latència no serà la d'un SSD local, a canvi guanyes la resiliència del NAS i la facilitat de gestionar còpies, migracions i restauracions ràpides.

Sobre Proxmox, molta gent aixeca un petit clúster k3s amb tres VMs d'Ubuntu LTS per al pla de control, afegint components com kube-vip (IP virtual d'alta disponibilitat), Longhorn (emmagatzematge distribuït i còpies automàtiques de volums), controladors d'ingrés com Traefik o Nginx, i eines d'observa. Tot això et permet desplegar serveis de l'homelab a Kubernetes usant Helm o manifests i versionar-ho amb Git.

A partir d'aquí, arriben les peces que fan que l'homelab “moli” de debò: Pi-hole per a DNS i bloqueig de publicitat; Home Assistant per integrar domòtica, càmeres i energia; Homebridge i Scrypted per integrar dispositius no suportats i càmeres a HomeKit; Plex o similars per a multimèdia; i tot plegat penjant dels teus VLANs i dels teus túnels Zero Trust ben lligats.

El resultat d'ajuntar segmentació, firewall estricte, DNS controlat, accés remot segur, monitorització i backups és un entorn domèstic que s'assembla molt a una infra moderna d'empresa però a escala casolana : amb menys soroll, més visibilitat, menys sorpreses quan cau alguna cosa i, sobretot, amb la tranquil·litat que una fallada en un trasto WiFi barat no hauria.