Mājas laboratorijas nostiprināšana ar VLAN: pilnīga mājas drošības rokasgrāmata

Informatec Digital » Resursi » Mājas laboratorijas nostiprināšana ar VLAN: pilnīga mājas drošības rokasgrāmata

Ja jums ir mājas laboratorija ar dažām ierīcēm (NAS, minidatoriem, Raspberry Pi, kamerām, viedās mājas ierīcēm utt.) un viss ir savienots vienā tīklā, jūsu mājas, digitāli runājot, ir atvērts lauks sānu kustībai un muļķīgiem uzbrukumiem . Jums nav jābūt lielam uzņēmumam, lai kāds skenētu jūsu portus, uzlauztu vāju paroli vai pakļautu lietu interneta ierīci drošības ievainojamībai.

Šī raksta mērķis ir soli pa solim sniegt norādījumus par segmentēta mājas tīkla iestatīšanu ar VLAN, ugunsmūri un spēcīgām aizsardzības metodēm. Tas nodrošinās, ka jūsu mājas pakalpojumi darbojas tikpat labi, bet ar ievērojami lielāku kontroli, mazāk negaidītu problēmu un daudz mazāku uzbrukumu virsmu . Mēs apvienosim labāko no vairākām pieejām: pfSense/OPNsense, UniFi, Zero Trust (Tailscale, Cloudflare Tunnel) , Proxmox, vieglmetāla Kubernetes, Pi-hole, Home Assistant un citas.

Kāpēc jūsu mājas laboratorijai tagad ir nepieciešama segmentācija un nostiprināšana

Klasiskā "plakanā" tīklā, piemēram, 192.168.1.0/24, kurā viss ir saspiests, jebkura ierīce var redzēt un daudzos gadījumos sazināties ar jebkuru citu ierīci. Ja tiek apdraudēta spuldzīte, televizors vai "viedā" kontaktdakša, uzbrucējs var mēģināt pārlēkt uz jūsu NAS , personālo datoru, Proxmox hipervizoru vai serveri, kurā glabājat dublējumkopijas . Tam nav nepieciešams sarežģīts uzbrukums; pietiek ar programmaparatūras ievainojamību, kuru neviens neaizlāpo.

Turklāt visu ierīču sajaukšana vienā tīklā izraisa nekontrolētu atklāšanas datplūsmu (apraidi, multiraidi, mDNS utt.). Tas rada troksni, sarežģī problēmu novēršanu un turklāt atklāj pārāk daudz informācijas par to, kas jums ir, kuras pieslēgvietas jūs izmantojat un kādi pakalpojumi darbojas jūsu lokālajā tīklā (LAN) . VLAN segmentācija risina tieši šo problēmu: atdala ierīces pēc funkcijas un uzticamības līmeņa.

Iedomājieties savu mājas laboratoriju kā nelielu datu centru: jums ir kritiski svarīgi pakalpojumi (DNS, VPN, krātuve), publiskie pakalpojumi (reversais starpniekserveris, lietojumprogrammas, kas ir pakļautas tuneļiem), neuzticamas ierīces (lietu internets, viesi, bērnu konsoles) un jūsu personīgais aprīkojums. Katrai grupai jāatrodas savā "joslā" un jāspēj sazināties ar citām tikai, izmantojot ļoti specifiskus un labi pamatotus ugunsmūra noteikumus.

VLAN mājas laboratorijā: koncepcijas, kuras jūs faktiski izmantosiet

VLAN nav maģija: tas ir vienkārši atsevišķs apraides domēns 2. slānī. Bieži tiek pieņemts, ka viens VLAN ir vienāds ar vienu IP apakštīklu, taču patiesībā tie ir atšķirīgi jēdzieni. VLAN nosaka, kā tiek atdalīti Ethernet kadri; apakštīkls nosaka, kā trafika tiek maršrutēta 3. slānī. Svarīgi ir tas, ka ierīces vienā VLAN neredz apraidi no cita, un tās var sazināties savā starpā tikai caur maršrutētāju vai ugunsmūri.

Atdalīšana tiek panākta, izmantojot 802.1Q tagus (VID, no 1 līdz 4095), ko komutatori ievieto paketēs. Ports var darboties divos pamata veidos: kā piekļuves ports , kur datplūsma ienāk un iziet nemarķēta un visa pieder vienam VLAN, vai kā maģistrālā porta , kur viens kabelis vienlaikus pārraida vairākus marķētus VLAN uz maršrutētāju, citu komutatoru, piekļuves punktu vai hipervizoru.

Labi zināmais PVID jeb Native VLAN nosaka, kurš VLAN tiek piešķirts nemarķētai datplūsmai, kas ienāk ostā. Katrs ražotājs to savā tīmekļa saskarnē attēlo atšķirīgi (PVID, Access VLAN, Native VLAN utt.), taču ideja ir viena: komutators izlemj, kuram VLAN pieder nemarķēts kadrs, un, kad tas tiek nosūtīts caur piekļuves portu, tas parasti noņem tagu, lai gala ierīce redzētu "parastu Ethernet" un tai nekas nebūtu jāzina par VLAN.

Tipiskā mājas laboratorijas iestatījumos starp ugunsmūri/maršrutētāju (pfSense, OPNsense, UniFi, OpenWrt utt.) un galveno komutatoru būs vismaz viena maģistrālā saite, un no turienes varēsiet piekļūt datoru, televizoru, konsolu, kameru utt. portiem. Turklāt, ja izmantojat Proxmox vai virtualizācijas resursdatoru, ir ļoti bieži konfigurēt maģistrālo saiti uz hipervizoru un ļaut virtuālajām mašīnām vai konteineriem tieši atzīmēt savu datplūsmu, izmantojot tiltus, piemēram, vmbr0, ar VLAN tagiem.

Praktisks VLAN dizains modernai mājas laboratorijai

Pirms drudžaini atverat komutācijas paneli, paņemiet papīru (vai teksta redaktoru) un definējiet, kurus tīklus vēlaties un kādam nolūkam. Saprātīgs izklāsts, kas aptver to, ko redzat daudzās reālās pasaules konfigurācijās, varētu izskatīties apmēram šādi, pielāgojot IP diapazonus un VLAN numurus savām vēlmēm:

• “Noklusējuma” vai mājas tīklsŠeit atrodas ģimenes personīgās ierīces (mobilie tālruņi, klēpjdatori, galddatori). Tas ir "uzticams" tīkls, un tam parasti ir nedaudz brīvākas interneta piekļuves atļaujas.
• Viesu VLANParedzēts apmeklētājiem. Tikai internets, nav piekļuves pārējiem privātajiem diapazoniem, ar izolāciju starp klientiem, ja piekļuves punkts to atļauj.
• IoT VLANSpuldzēm, rozetēm, skaļruņiem, viedtelevizoriem, termostatiem, robotizētiem putekļsūcējiem utt. Ļoti ierobežota satiksme uz iekšu un kontrolēta satiksme uz āru.
• VLAN mājas laboratorija / PakalpojumiŠeit atrodas jūsu virtuālās mašīnas, konteineri, NAS, Home Assistant, datubāzes, reversie starpniekserveri utt. Parasti tā sazinās ar lietu internetu (IoT) un noklusējuma serveri, bet ļoti kontrolētā veidā.
• VLAN “Drošs” vai VPN: segments, kurā visa datplūsma uz internetu iet caur pastāvīgu VPN tuneli (piemēram, Proton VPN vai līdzīgu), ierīcei neinstalējot klientu.
• DMZ: neobligāts, bet ļoti ieteicams potenciāli neaizsargātiem pakalpojumiem (apgrieztais starpniekserveris, tīmekļa serveri, VPN utt.), apstrādājot tos kā "daļēji uzticamus" pakalpojumus bez tieša tilta uz pārējiem iekšējiem tīkliem.

Skaidrs veids, kā organizēt privātās adreses, ir izmantot kaut ko līdzīgu 10.10.X.0/24 katram VLAN un uzturēt izklājlapu ar diapazoniem, nosaukumiem un mērķiem . Piemēram: 10.10.10.0/24 Default, 10.10.20.0/24 IoT, 10.10.30.0/24 Guests, 10.10.40.0/24 Homelab, 10.10.50.0/24 Secure. Tas laika gaitā ievērojami atvieglos ugunsmūra noteikumu un DHCP rezervāciju uzturēšanu.

Ja izmantojat UniFi vai līdzīgus risinājumus, parasti katru VLAN kontrollerī tiek piesaistīts tīklam un savukārt katrs tīkls tiek saistīts ar konkrētu SSID. Tādā veidā, izvēloties Wi-Fi tīklu “Mājas”, “Lietu internets”, “Viesis” vai “VPN”, ierīce automātiski nonāk pareizajā VLAN un manto šim segmentam definētās ugunsmūra un piekļuves politikas.

Aparatūras un programmatūras izvēle VLAN un maršrutēšanas pārvaldībai

Kas attiecas uz komutatoru, ja vien tas atbalsta 802.1Q un ļauj konfigurēt VLAN atzīmēšanu, maģistrāles un PVID, viss ir kārtībā. Lielākā atšķirība ir tajā, vai ierīce veic tikai 2. slāņa komutāciju vai arī apstrādā 3. slāņa maršrutēšanu līnijas ātrumā . Daudzi "budžeta" komutatori var atzīmēt un pārsūtīt kadrus lielā ātrumā, taču, kad tiem lūdz maršrutēt datplūsmu starp VLAN, tie to novirza uz centrālo procesoru, un caurlaidspēja samazinās līdz dažiem simtiem Mb/s.

Ja vēlaties vienkāršot lietas, visizplatītākā pieeja mājas laboratorijā ir atstāt starp-VLAN maršrutēšanu galvenajam ugunsmūrim/maršrutētājam (pfSense, OPNsense, UniFi Security Gateway, Dream Machine, OpenWrt uz pienācīga maršrutētāja utt.) un izmantot slēdžus tikai 2. slānim. Ja jūsu iekšējā datplūsma ir ļoti liela (kopijas starp krātuves masīviem, virtualizācijas klasteriem, lieliem dublējumkopiju kopumiem), varētu būt vērts izmantot 3. slāņa slēdzi ar aparatūras maršrutēšanas atslodzi , taču lielākajai daļai māju tas nav nepieciešams.

Runājot par programmatūru, ir trīs galvenie ceļi:

• openwrt en pieticīgi maršrutētāji Sākumā tai ir iespēja marķēt ostas, izveidot vairākus tīklus un piemērot pamata ugunsmūra noteikumus.
• pfSense vai OPNsense x86 datorā (bezvadu datorā vai virtuālajā datorā), ja vēlaties paplašinātus noteikumus, GeoIP, IPS/IDS, jaudīgus VPN, augstu pieejamību ar CARP utt.
• Unifi (Dream Machine, Dream Router utt.), ja vēlaties integrētu vidi ar piekļuves punktiem un slēdžiem, ko pārvalda viens kontrolieris, ar nedaudz maigāku apguves līkni.

Hipervizora ziņā Proxmox patiesi izceļas sarežģītos tīklos: vienkārši izveidojiet tiltus, kas saistīti ar fiziskajām tīkla kartēm (piemēram, vmbr0 pār enp1s0), norādiet šo komutatora portu kā maģistrālo portu un ļaujiet katrai virtuālajai mašīnai vai konteineram to atzīmēt ar nepieciešamo VLAN ID. Tas ļauj vienam serverim vienlaikus būt daļai no vairākiem VLAN un darboties, piemēram, kā resursdatoram mājas laboratorijas pakalpojumiem, kuriem var piekļūt no noklusējuma un lietu interneta, neprasot sarežģītu komutatoru iestatīšanu.

No teorijas līdz praksei: VLAN izveide un testēšana

Kad dizains ir izlemts, jūs definējat katru VLAN komutatorā ar tā VID un aprakstošu nosaukumu. Pēc tam jūs norādāt portus, kas savienojas ar maršrutētāju/ugunsmūri, citiem komutatoriem un Proxmox, kā maģistrālās pieslēgvietas, ļaujot izmantot VLAN, kurus vēlaties pārnēsāt. Šajās pieslēgvietās vislabāk ir izvairīties no dažādu vietējo VLAN izmantošanas katrā galā, lai novērstu nemarķētas datplūsmas noplūdes vai neparastu uzvedību.

Porti, kuriem pievienosiet "nepilnīgas" ierīces (televizoru, spēļu konsoli, datoru bez VLAN atbalsta, kameras), jānorāda kā piekļuves porti: viens, nemarķēts VLAN ar atbilstošu PVID. Tādā veidā šī ierīce vienmēr atradīsies jūsu izvēlētajā tīklā, novēršot nejaušu savienojumu ar citu tīklu konfigurācijas kļūdas dēļ.

Ugunsmūrī/maršrutētā jūs izveidojat loģisku saskarni katram tagam, kas iet caur tīkla karti, kas pievienota slēdzim. Piemēram, pfSense un OPNsense ļauj izveidot VLAN saskarnes fiziskā tīkla kartē, un jūs piešķirat katrai saskarnei IP adresi, DHCP diapazonu, DNS serveri, aprakstu un, pats galvenais, savus neatkarīgos ugunsmūra noteikumus . Šie katras saskarnes noteikumi ir izolācijas atslēga.

Kad tas ir konfigurēts, ir pienācis laiks pārbaudei: pievienojiet klēpjdatoru IoT piekļuves portam, pārbaudiet, kādu IP adresi tas saņem, pārbaudiet, kuru vārteju un DNS tas redz, un pārliecinieties, ka tas nevar nosūtīt ping ziņojumu uz noklusējuma vai mājas laboratorijas apakštīkliem, bet vai tas atpazīst publiskos domēnus un piekļūst internetam (ja tas ir tas, ko vēlaties). Atkārtojiet līdzīgus vingrinājumus viesiem, mājas laboratorijai un drošajam tīklam, līdz esat pārliecināts, ka katrs tīkls darbojas, kā paredzēts.

Ugunsmūris un noteikumi sānu kustības bloķēšanai

Visefektīvākā pamatpieeja ir pēc noklusējuma liegt un atļaut tikai nepieciešamo . Tas ir, katrā VLAN izveidojat sākotnējo noteikumu, kas atļauj "izveidotu/saistītu" datplūsmu (lai atļautu atbildes uz iekšienes uzsāktiem savienojumiem) un pēc tam liedz datplūsmu uz citiem privātiem tīkliem (RFC1918 tipi), izņemot pamatotus izņēmumus.

Ērta metode ir izveidot IP adrešu grupu, kurā ir visi jūsu privātie bloki (piemēram, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12), un atsaukties uz to savos noteikumos. Tādā veidā noteikums, kas bloķē “IoT → PrivateNetworks”, nekavējoties neļauj spuldzēm un citām ierīcēm sazināties ar jūsu NAS vai klēpjdatoru, atstājot piekļuvi tikai internetam un, ja nepieciešams, konkrētiem mājas laboratorijas pakalpojumiem.

Noklusējuma tīklā varat atļaut "LAN uz jebkuru vietu" (internets + citi VLAN), taču ieteicams turpināt ierobežot piekļuvi demilitarizētajai zonai (DMZ) vai noteiktiem sensitīviem serveriem. Viesu tīklos tomēr ir normāli bloķēt visu piekļuvi privātiem diapazoniem un atļaut tikai piekļuvi internetam. Ja piekļuves punkts atbalsta klienta izolāciju, iespējojiet to, lai apmeklētāju mobilās ierīces pat nevarētu redzēt viena otru.

Attiecībām starp Homelab un IoT tipisks modelis ir atļaut vienam resursdatoram (piemēram, Home Assistant konteineram vai virtuālajai mašīnai) sasniegt noteiktas IoT ierīces noteiktos portos (API portā, vadības portā), bet ne otrādi. Tas tiek ieviests ar atļautu noteikumu, piemēram, “HomelabHost → IP_IoT:port”, kam seko vispārēja Homelab un Default IoT bloķēšana, izņemot izveidoto datplūsmu.

Padarīt multiraidi, mDNS un tamlīdzīgas darbības par murgu

Tiklīdz sākat atdalīt tīklus, jūs saprotat, ka tādas lietas kā AirPlay, Chromecast vai daži printeri "pazūd". Tā nav kļūda: daudzi atklāšanas mehānismi izmanto apraidi vai multiraidi un pēc būtības nepārvietojas starp VLAN. Lai tie darbotos, jums ir jābūt selektīvam attiecībā uz to, kādu atklāšanas trafiku atļaujat.

Parasti komutatoros tiek iespējota IGMP snooping funkcija, lai ierobežotu multiraidi tikai uz tām pieslēgvietām, kurās ir ieinteresēti klienti. Pēc tam maršrutētājā/kontrollerī tiek iespējota mDNS/Bonjour releja vai līdzvērtīga pakalpojuma funkcija, skaidri norādot, starp kuriem VLAN vēlaties pārsūtīt reklāmas (piemēram, starp Default un IoT vai starp Default un Homelab).

UniFi tīklā, iespējams, būs jāizveido arī LAN-IN noteikumi, kas atļauj mDNS portu un datplūsmas veidu, vai jāpielāgo daudzadresācijas profili katram SSID. Vislabāk ir rīkoties piesardzīgi: iespējojiet releju tikai starp segmentiem, kas faktiski ir jāpieslēdz, un pārliecinieties, vai starp tīkliem, kurus plānojāt izolēt, nenoplūst nevajadzīga informācija.

Dažas ierīces, piemēram, Sonos, slikti apstrādā VLAN un var radīt daudz problēmu pat ar tehniski konfigurētiem relejiem. Daudzi cilvēki galu galā atstāj tās noklusējuma tīklā (vai īpašā multimediju VLAN) un pieņem, ka šī daļa nebūs tik segmentēta apmaiņā pret visu, kas darbojas, bez nepieciešamības cīnīties ar ražotāja programmaparatūru.

Droša pārvaldība: MFA, SSH ar atslēgām un nulles uzticēšanās

Jūsu ugunsmūris, Proxmox resursdatori, NAS ierīces un pārvaldības pakalpojumi ir atslēga uz valstību. Nav pieņemami atstāt saknes lietotājam vienkāršu paroli, kas pieejama no jebkuras vietas. Saprātīgākā pieeja ir izveidot īpašu administratora kontu ugunsmūra tīmekļa panelim, atspējot tiešu root piekļuvi un vienmēr iespējot divfaktoru autentifikāciju (piemēram, TOTP pakalpojumā OPNsense).

Turklāt ir ļoti ieteicams ierobežot piekļuvi šīm pārvaldības konsolēm tikai ar noteiktu IP adresi vai apakštīklu uzticamo ierīču VLAN ietvaros (piemēram, jūsu galveno galddatoru vai klēpjdatoru). Tādā veidā, ja kādam izdodas ielauzties citā tīklā vai apdraudēt IoT ierīci, viņam nebūs viegli piekļūt ne ugunsmūra panelim, ne hipervizora pārvaldības saskarnei.

Lai piekļūtu serveriem un virtuālajām mašīnām, izmantojot SSH, vislabāk ir pilnībā atspējot paroles autentifikāciju un izmantot tikai publiskās atslēgas . Varat iet vēl tālāk un ieviest otru faktoru, izmantojot tādus risinājumus kā Duo: pat ja kāds nozog jūsu privāto atslēgu, pieteikšanās mēģinājums ģenerē apstiprinājumu jūsu mobilajā ierīcē, un, ja jūs to neautorizējat, savienojums tiek noraidīts.

Attālinātās piekļuves gadījumā vēstījums ir skaidrs: pārtrauciet atvērt tiešās pieslēgvietas (80, 443, 22 utt.) savā maršrutētājā. Tā vietā izmantojiet nulles uzticēšanās risinājumus, piemēram, Tailscale (tīkla VPN, ko nodrošina WireGuard), Cloudflare Tunnel vai Twingate. Šie rīki ļauj jums piekļūt iekšējiem pakalpojumiem autentificētā un šifrētā veidā, nepublicējot savu IP adresi vai pieslēgvietas internetā . Jūsu tīmekļa lietotnes, informācijas paneļi un SSH savienojumi kļūst pieejami tikai pēc iepriekšējas autentifikācijas un ar stingrām piekļuves politikām.

Nocietināt konteinerus, sistēmas un pakalpojumus

Konteineri rada maldīgu drošības sajūtu: tie ir izolēti, jā, bet, ja visu darbināt privileģētā režīmā, koplietojot rakstīšanas apjomus visur un izmantojot neuzturētus attēlus, jūs nonākat tikpat neaizsargāti kā pakalpojumi, kas instalēti tieši resursdatorā. Galvenais ir izmantot oficiālus vai ļoti uzticamus attēlus , regulāri atjaunināt un izvairīties no karodziņa "privileģēts", izņemot ļoti specifiskus gadījumus.

Kad vien iespējams, statiskajiem datiem pievienojiet tikai lasāmus sējumus, atdaliet datu konfigurācijas un ierobežojiet konteineru iespējas līdz minimumam. Pārbaudiet Docker ligzdas atļaujas un nepakļaujiet sensitīvus paneļus, piemēram, Portainer, tieši internetam; novietojiet tos aiz droša reversā starpniekservera ar papildu autentifikāciju vai aizsargājiet tos, izmantojot Tailscale/Cloudflare Tunnel.

Bāzes sistēmās (Raspberry Pi, miniPC, Linux VM) ir jāievēro pamata higiēna: jāmaina noklusējuma paroles, jāiespējo regulāri atjauninājumi, jāatspējo neizmantotie pakalpojumi, jākonfigurē UFW vai līdzvērtīgs ugunsmūris ar noklusējuma liegšanas politiku un jāatļauj piekļuve tikai nepieciešamības gadījumā . Pakalpojumiem, kas bieži tiek uzbrukti, piemēram, SSH, Fail2Ban vai moderni rīki, piemēram, CrowdSec, var palīdzēt bloķēt brutālas piespēles mēģinājumus.

Attiecībā uz šifrētu saziņu vairs nav praktiski apkalpot jebko vienkāršā HTTP protokolā, pat lokālajā tīklā (LAN). Apgrieztie starpniekserveri, piemēram, Caddy, Nginx Proxy Manager vai Traefik, atvieglo TLS sertifikātu (Let's Encrypt u. c.) izmantošanu un ļauj pievienot papildu autentifikācijas slāni, ātruma ierobežošanu, drošības galvenes un citus elementus gan iekšējai datplūsmai, gan datplūsmai, kas iet caur nulles uzticamības tuneļiem.

DNS, Pi-hole un DoH “melnā saraksta” bloķēšana

Svarīgs privātuma un tīkla kontroles aspekts ir sava DNS pārvaldība. Lieki izvietota Pi-hole (vai AdGuard Home) ļauj bloķēt reklāmas, telemetriju un aizdomīgus domēnus tīkla līmenī, nekonfigurējot pārlūkprogrammas paplašinājumus katrā ierīcē. Tomēr jums ir jāizveido stabila infrastruktūra, kuru ir grūti atspējot un apiet.

Runājot par DNS pastiprināšanu, ideja ir tāda, ka visas ierīces veiks vaicājumus tikai jūsu Pi-hole serveriem un nevarēs brīvi piekļūt 1.1.1.1, 8.8.8.8 vai publiskām DNS adresēm, izmantojot HTTPS. Tiem, kas uzstāj uz DHCP DNS ignorēšanu, varat izveidot IP adrešu kopas, kas satur galveno publisko DNS un DoH pakalpojumu sniedzēju (Cloudflare, Google, Quad9 utt.) adreses, un rakstīt ugunsmūra noteikumus, kas atļauj DNS pieprasījumus tikai tad, ja tie nāk no jūsu Pi-hole serveriem, un bloķē tos visiem pārējiem.

Praksē parasti tiek definēti grupu profili, piemēram, "Pi-hole serveri" un porti "DNS" un "TLS-DoH". Pēc tam tiek pievienoti izejošie noteikumi, kas ļauj Pi-hole sazināties ar internetu šajos portos, un tieši zem šiem noteikumiem tiek novērsti jebkādi mēģinājumi izmantot šos pašus portus no citām IP adresēm lokālajā tīklā. Tādā veidā ikviens, kas mēģinās izmantot savus DNS serverus, zaudēs izšķirtspēju un "iemācīsies" respektēt jūsu konfigurāciju.

Lai Pi-hole būtu noturīgs, ieteicams instances mitināt dažādās ierīcēs (piemēram, vienā konteinerā NAS, citā Proxmox un vēl vienā Raspberry Pi ar SSD) un konfigurēt DHCP, lai klientiem piešķirtu vairākas DNS IP adreses. Tādā veidā, ja viens mezgls neizdodas, jūs nezaudēsiet piekļuvi internetam, un pakalpojums turpinās darboties, kamēr jūs izmeklēsiet problēmu.

Nulles uzticēšanās un attālināta piekļuve ar Cloudflare Tunnel un Tailscale

Tā vietā, lai atvērtu tiešus tiltus uz mājām, varat izmēģināt ļoti spēcīgu kombināciju: Cloudflare Zero Trust, lai piekļūtu atlasītiem tīmekļa pakalpojumiem (ar identitātēm, politikām un auditēšanu), un Tailscale, lai piekļūtu iekšējiem resursiem, izmantojot tīkla VPN, it kā jūs atrastos lokālajā tīklā (LAN), bet nepieskaroties maršrutētāja NAT.

Cloudflare Tunnel (ar cloudflare klientu, kas darbojas kā konteiners vai pakalpojums) izveido izejošos tuneļus no jūsu tīkla uz Cloudflare infrastruktūru. No turienes jūs saistāt apakšdomēnu ar šo tuneli un novirzāt HTTPS trafiku uz vienu vai vairākiem pakalpojumiem jūsu mājas laboratorijā. Neviens neredz jūsu mājas IP adresi vai portus; viņi redz tikai domēnu, ko aizsargā Cloudflare slāņi, kur varat ieviest pieteikšanos, 2FA, ģeogrāfiskos filtrus un citas funkcijas.

Lai nodrošinātu tradicionālu VPN piekļuvi visam tīklam vai noteiktiem segmentiem, Tailscale ir fantastisks risinājums. Tas instalējas ar vienkāršu skriptu, reģistrē katru ierīci jūsu "tailnet" tīklā un izveido privātu tīklu, kura pamatā ir WireGuard, ar ACL, lai noteiktu, kuri lietotāji var piekļūt kurai IP adresei un portam. Tādā veidā jūs varat ierobežot piekļuvi, piemēram, tikai saviem personīgajiem kontiem, ļaujot tiem piekļūt 192.168.1.10:22 (hipervizors) vai 10.10.40.100:3000 (jūsu CI rīks).

Ja vēlaties spert soli tālāk, varat aprakstīt visu nulles uzticēšanās konfigurāciju Terraform platformā, izmantojot Cloudflare. Tas saglabā jūsu politiku kā kodu, ļauj veikt izmaiņas reproducējami un nodrošina versiju kontroli Git platformā, tāpat kā jebkurā citā infrastruktūras projektā. Tas ir ļoti profesionāls veids, kā pārvaldīt savu mājas laboratoriju, pat ja tā vienkārši atrodas skapī gaitenī.

Kabeļi, aizkave un tipiskas veiktspējas problēmas

Loģiskā aizsardzības nodrošināšana nelīdzēs, ja fiziskais tīkls ir nekam nederīgs. Vecu RJ11 ligzdu un kabeļu atkārtota izmantošana varētu būt pagaidu risinājums, taču tīkla savienojumu laikā lielas slodzes apstākļos bieži var rasties pārtraukumi, CRC kļūdas vai ātruma kritumi. Kad vien ir iespēja (būvniecība, renovācija, mēbeļu pārvietošana), apsveriet iespēju izmantot augstas kvalitātes CAT6 vai CAT7 kabeļus un komutācijas paneļus ar atbilstošiem savienotājiem.

Savienojot telpas vai skapjus ar vairākiem komutatoriem, maģistrālā saite bieži vien ir sašaurinājums. Ja pamanāt, ka datplūsma starp zonām kļūst pārslogota, apsveriet iespēju grupēt vairākas fiziskās saites saišu apvienojumā (LAG), ja vien komutatori to atbalsta. Tas palielina pieejamo joslas platumu un nodrošina lielāku noturību pret kabeļu bojājumiem.

Fiziski dokumentējot, kur atrodas katra pieslēgvieta, kurš VLAN ID tiek izmantots katrā segmentā un kā tiek konfigurēti vietējie VLAN, nākotnē ietaupīsiet stundas. Marķējiet kabeļus, anotējiet pieslēgvietas un sinhronizējiet tās ar savu loģisko VLAN diagrammu. Liela daļa tīkla "noslēpumu" izrādās nepareizi marķēta pieslēgvieta vai nepareizs VLAN ID.

Kad kaut kas noiet greizi (neprātīgi latentumi, beidzies TTL, atkārtoti maršruti), izmantojiet pamata rīkus: maršruta izsekošanu no dažādiem punktiem (klients, maršrutētājs, modems), kļūdu skaitītājus saskarnēs, pakešu uztveršanu ugunsmūrī un, ja jūsu komutators to atļauj, porta spoguli, lai redzētu, kuras etiķetes un MAC adreses faktiski cirkulē caur problemātisko saiti, un izpildiet mūsu rokasgrāmatu, lai novērstu savienojuma problēmas.

Mājas laboratorija kā laboratorija: Proxmox, vieglsvarīga Kubernetes un galvenie pakalpojumi

Kad tīkla un drošības pamati ir izveidoti, mājas laboratorija kļūst par brutālu testēšanas poligonu, kur praktizēt lietas, kas ir ļoti līdzīgas ražošanas videi: klasterus ar Proxmox, vieglus Kubernetes, piemēram, k3s, NFS no NAS kā koplietojamu krātuvi, dublējumus, augstu pieejamību utt.

Proxmox ļauj jums organizēt virtuālās mašīnas un konteinerus, izmantojot vienkāršu tīmekļa saskarni, vietējo klasterizāciju, momentuzņēmumus un iebūvētas dublējumkopijas. Varat pievienot NFS no sava NAS un izmantot to kā koplietojamu krātuvi virtuālajiem diskiem, dublējumkopijām vai ISO. Lai gan latentums nebūs tik liels kā lokālajam SSD, jūs iegūsiet NAS noturību un dublējumu, migrācijas un ātras atjaunošanas pārvaldības vienkāršību.

Proxmox platformā daudzi cilvēki izveido nelielu Kubernetes klasteri ar trim Ubuntu LTS virtuālajām mašīnām vadības plaknei, pievienojot tādus komponentus kā kube-vip (augstas pieejamības virtuālā IP adrese), Longhorn (izkliedēta krātuve un automātiska sējumu dublēšana), ieejas kontrollerus, piemēram, Traefik vai Nginx, un novērošanas rīkus (Prometheus, Grafana, Loki). Tas ļauj izvietot mājas laboratorijas pakalpojumus Kubernetes platformā, izmantojot Helm vai manifestus un versiju kontroli ar Git.

No turienes nāk elementi, kas padara mājas laboratoriju patiesi “foršu”: Pi-hole DNS un reklāmu bloķēšanai; Home Assistant mājas automatizācijas, kameru un enerģijas integrēšanai; Homebridge un Scrypted neatbalstītu ierīču un kameru integrēšanai HomeKit; Plex vai līdzīgs multimedijiem; un tas viss darbojas jūsu VLAN un labi aizsargātajos nulles uzticamības tuneļos.

Segmentācijas, stingra ugunsmūra, kontrolēta DNS, drošas attālinātās piekļuves, uzraudzības un dublējumu apvienojuma rezultāts ir mājas vide, kas ļoti atgādina mūsdienīgu uzņēmuma infrastruktūru, bet mājas mērogā : ar mazāku troksni, labāku redzamību, mazāk pārsteigumiem, ja kaut kas noiet greizi, un, pats galvenais, sirdsmieru, ka lētas WiFi ierīces kļūmei nevajadzētu pārvērsties par lielu drāmu.