Bevezetés, DHCP ütközés
A munkahelyemen 1,5 éve heterogén környezetben használom a FOG Project nevű hálózatos rendszerkép készítő programot. A segítségével 20-30 gépet 3 nap alatt újratelepítek úgy, hogy még a tartományba (domain) is belépteti a FOG. Először csinálok egy minta gépet olyan módon, hogy a Windows telepítőben belépek az Audit módba. Amikor már felmásolta a fájlokat és elindul a telepítővarázsló (ahol kérdezi az országot, billentyűzetkiosztást) azon a ponton a Ctrl + Shift + F3 billentyűkombinációt lenyomom, az ötletet ez a LOGOUT cikk adta még évekkel ezelőtt. Ebben a módban feltelepítem a szükséges programokat, aztán a Sysprep-el általánosítom az elkészült rendszert, majd a FOG-al lementem és végül Multicast módban 5-7 gépre párhuzamosan visszaküldöm (az 1 Gbit-es belső hálózat a korlátozó tényező) a rendszerképet a többi gépre. Aztán a FOG Client-je (Agent) elvégzi a beállított paraméterek alapján a domain-be léptetést is.
A FOG egy Proxmox alapú AlmaLinux 9 virtuális gépen van, a DHCP szerver egy Hyper-V alapú Windows Server, azok a kliensgépek, amikről a mentés készül, pedig Windows 11-es asztali számítógépek. VLAN-ok biztosítják az alhálózatok közötti szeparációt és a helyes hálózati beállításokat (a VLAN a hálózatos kollégák érdeme). Ezt szerettem volna egy homelabban megoldani úgy, hogy mindhárom gép (FOG, DHCP szerver, Windows kliens) Hyper-V alapokon legyen. A fő célom ezzel a gyakorlás és egy videós anyag (videósorozat) készítése YouTube-ra a saját csatornámra. Ez a megoldás könnyen reprodukálható, ugyanis a legtöbb Windows 10 és 11 (kiadástól függően) képes Hyper-V alapú virtualizációra.
A fő probléma, hogy a FOG Project a rendszerképek mentését PXE módban csinálja. Azaz egy speciális bootolási folyamat során betölt egy egyszerű Linux alapú operációs rendszert azaz FOS (FOG Operating System) Linux-ot, ami a FOG saját Linux forkja. A Proxmox-on futó FOG-nak és a munkahelyi VLAN-okkal elszeparált hálózatnak ezzel nem volt baja, azonban az otthoni homelab környezetemben a Hyper-V alapú FOG elhasalt. Általában nem találta a Windows 11 a PXE boot során a FOG-ot, vagy ha esetleg be is töltött, akkor a PXE folyamat váratlanul megszakadt. Mint kiderült, DHCP ütközés volt a szolgáltató által adott eszköz DHCP szervere és a DHCP szerverként is üzemelő Windows Server között, emiatt volt megbízhatatlan a PXE folyamat.
Nem adtam fel, néhány hónap múlva újra megépítettem a homelab-ot és egy fontos segítőtársam is akadt a Copilot AI személyében. Segített rávezetni arra, hogy építsek olyan homelabot, ami el van szigetelve az otthoni hálózatomtól és a Hyper-V hosttól, így elkerülhető a DHCP ütközés és a PXE folyamat megszakadása, megbízhatatlansága.
Hirdetés
Részben újragondolt homelab
Az a megoldás lett a célravezető, hogy létrehozok egy belső hálózatot a virtuális gépek között, ami nincs kapcsolatban a fizikai otthoni hálózattal, így a Telekomos eszközömmel sem. A Windows Servernek két hálózati adaptere van, a default switch, egy NAT-olt hálózati adapter, ami a host gép hálózati kártyáján át eléri az internetet. Kap még egy belső hálózati kártyát, amin keresztül tud kommunikálni a másik két virtuális géppel. A maradék két virtuális gép csak a belső hálózati kártyát kapja, így az elszeparált hálózat megoldott, azonban a helyzet az, sem a Windows 11, sem az FOG Project alapját adó AlmaLinux nem éri el az internetet.
Erre hoztam létre egy NAT-ot a Windows Serveren, valamint a Windows Server mindkét hálózati adapterére beállítottam IP-továbbítást. Nem bonyolult, 3 db PowerShell parancs az egész, egyedül a DHCP-t és a Windows Server hálózatát kell jól beállítani.
A NAT létrehozását így csináltam:New-NetNat `-Name "FOGLabNAT" `-InternalIPInterfaceAddressPrefix "192.168.100.0/24"
Az utolsó sorba helyettesítsd be a saját homelab-od belső hálózatát és netmaszkját!
A /24 az IP cím végén azt jelenti, hogy a 192.168.100.0 és 192.168.100.255 közötti IP címeket kaphatják meg a gépek az alhálózatban, mivel a netmaszk 255.255.255.0. A DHCP szerver fix IP címe a 192.168.100.1, a FOG fix IP címe 192.168.100.10. A Windows 11 kliensek DHCP-n át kapnak a 192.168.100.100 és a 192.168.100.200-as tartományból IP címet a Windows Servertől. A /24-et CIDR megadási módnak hívják, rengeteg online CIDR kalkulátort találhatsz.
A FOG szervernek és a Windows 11 klienseknek a Windows Servert állítottam be átjáróként. DNS szerepkört nem telepítettem, így a Windows Server és a másik 2 virtuális gép is az 1.1.1.1-es Cloudflare DNS feloldót használják.
Az IP-továbbítást az alábbi 2 db PowerShell parancs csinálja:Set-NetIPInterface `-InterfaceAlias "Ethernet" `-Forwarding Enabled
Set-NetIPInterface `-InterfaceAlias "Ethernet 2" `-Forwarding Enabled
Ezzel elérem azt, hogy a Windows Server "Ethernet" és "Ethernet2" nevű hálózati adapterein bekapcsolásra kerül a Forwarding.
A NAT és az IP-továbbítás működését ez az egyszerű ábra szemlélteti a legjobban: 
A DHCP és IP beállítások
Mint említettem a Windows 11 klienseknek (jelen esetben 1 db) a Windows Server oszt IP címet. A FOG szerveren is beállítom ugyanazt a DNS-t és Gateway-t (átjáró), amit a DHCP oszt ki.
DHCP által kiosztott IP tartomány: 192.168.100.100-192.168.100.200
DHCP paraméterek:
- 003 Útválasztó: 192.168.100.1 (A Windows Server fix IP címe)
- 006 DNS kiszolgáló: 1.1.1.1
- 066 Rendszerindítási kiszolgáló állomásneve: 192.168.100.10 (A FOG Project szerver IP címe)
- 067 Rendszerindítási fájl neve: ipxe.efi (PXE boot során ezt tölti be a számítógép)
Így az elszeparált hálózatban hibátlanul működik a PXE boot folyamat, sikeresen fel tudok venni kliens gépeket a FOG szerverre, valamint egy teszt mentést is lefuttattam.
Snapin, amit meg kell oldani
Azzal szembesültem, hogy a Snapin, azaz a távoli kódfuttatás (PowerShell, Batch, Bash, VB script), illetve a távoli alkalmazástelepítés (.msi fájl) még nem működik tökéletesen. Amit eddig teszteltem, hogy Winget-el frissítem a programokat. A FOG Project SYSTEM felhasználóként futtatja a scriptet, de valamiért a SYSTEM felhasználó Hyper-V környezetben nem tudja használni a Winget-et.
Csak akkor működik, ha a Hyper-V hoston futtatom a scriptet, a Windows 11-et tartalmazó virtuális gépen nem fut le. PsExec-el is nyomoztam, azt látom, hogy a virtuális gépként telepített Windowsban megmagyarázhatatlan okból nincs telepítve a Winget néhány komponense a SYSTEM felhasználónak. Igyekszem majd ennek okára is rájönni, mert a Hyper-V-vel ellentétben a munkahelyi asztali gépeken gond nélkül tudok így programokat frissíteni és esetleg telepíteni.
Ezt a PowerShell scriptet használom:#Fog PowerShell Script Snapin for WinGet#Find the directory for Winget due to folder changes, why does this need to be changed?!$fullwingetloc = Get-Childitem -Path 'C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller*' -Include WinGet.exe -Recurse | Select -ExpandProperty FullName& "$fullwingetloc" upgrade -s winget --all --accept-source-agreements --accept-package-agreements
Összegzés, videó
Ha szeretnél te is egy saját homelab-ot kialakítani, esetleg ötletet venni a FOG élesben történő bevetéséhez, akkor nézd meg azt a videómat, amiben telepítem a három virtuális gépet, létrehozom az elszigetelt hálózatot, beállítom a DHCP-t, a NAT-ot és az IP-továbbítást.
Tervezem videós formában is bemutatni a FOG Project telepítését és az első rendszerkép elkészítését is.
Köszönöm, hogy elolvastad az írásomat, ha észrevételed, véleményed van vele kapcsolatban, kérlek írj egy hozzászólást.
Ha van már tapasztalatod a FOG-al, nyugodtan írd meg az is a komment szekcióban.
