xcp-ng port forwarding to VM's - hogyan?

Virtualizáció

Sziasztok, segítsetek kérlek!

Egy új hardveren újoncként próbálgatnám az xcp-ng virtualizációs platformot, ami majd később, ha már van kellő tapasztalat, kikerülne az internetre produkciós feladatra.
A hálózatnál elakadtam.
Ha egy darab publikus IP alatt van kapcsolat a külvilággal, és ez alatt az IP alatt többféle protokollt kell kiszolgálni (https/pop3/ssh/vpn stb...) és ezeket a szolgáltatásokat egyenként külön VM-ek biztosítják, hogyan tudom megoldani a beépített open vSwitch segítségével, hogy az egyes portokat a különböző VM-ek felé irányítsa?
Persze lehet, hogy teljesen tévúton járok és ez az open vSwitch nem erre való és más megoldásra van szükség. A manual nem szól ilyen lehetőségről:
https://xcp-ng.org/docs/networking.html

A jelenlegi éles szerveren debian alatti XEN-t használok és az ipvsadm tool segítségével sikerült ezt megoldanom. Újraindulás esetén is szépen visszaállítja a szabályrendszert.
Igaz, az ipvsadm egy load-balancer célú eszköz, de erre a feladatra is jó volt.
Gondoltam manapság vannak erre korszerűbb megoldások, de furcsa módon nem találok leírást erre az egy publikus IP esetre (amiről pedig azt gondolnám, hogy általános igény. Vagy mindenki annyi publikus IP-t bérel, ahányféle szolgáltatást futtat??)
Nagyon köszönök előre is bármilyen iránymutatást!!

( golgota | 2024. 02. 12., h – 14:29 )

Szerkesztve: 2024. 02. 12., h – 14:30

Hat ide NAT vagy LB kell. Az openvswitch-ben van valami flow table (de nem vagyok expert, csak amit itt a network varazslok muvelnek abbol hallok ezt azt) es ott lehet ilyeneket allitgatni (ha minden igaz).

De egy jo kis HA proxy is megcsenalja neked szerintem.

Majd jonnek az okosok es megmondjak. 

( godot v | 2024. 02. 12., h – 14:35 )

Out of the box megoldás nincs az L3-L7 network funkciókra az Xcp-ng-ben.

Vagy egy(több) külön "router" VM-el oldod meg, vagy a hypervisor hoston kézzel megoldod mint most a Debian-os XEN hostodon ,bár ez utóbbi nem igazán támogatott megoldás frissítéseket lehet eltöri, vagy külső routert használsz erre.

A fizetős XOA-ban van már valamilyen SDN megoldás, de nem tudom az mit tud.

Az OVS meg általában az SDN az nem a layer3 vagy magasabb rétegek megoldása, hanem a layer2-é... Az OpenVSwitch egy switch, nem router... Sehol sem tud port forward-ot meg NAT-ot, mert nem layer3 megoldás, hanem layer2.

Proxmox-on annyival könnyebb, hogy az alapul szolgáló Debian nincs kicsontozva, és percek alatt lehet IPtables-sel tűzfalat és NAT-ot konfigurálni, route-olni meg alapból tud (és az IP forward is aktív...). Míg az xcp-ng egy nagyon lekönnyített type1 hypervisor (mint a VMware ESXi), ami semmi mást nem szolgál, mint virtuális gépek futtatását. Kb. annyi layer3 hálózati funkció van benne, amennyi a menedzsmentjéhez kell.

Ennek ellenére Proxmox host-on sem csinálnél route-ot meg NAT-ot.

Azért nincs ilyen, mert ezt nem hypervisor szinten kell megoldani...

Sőt, szerintem csak a bajt csinálod magadnak, ha a virtualizáló host-on csinálod meg.

Vagy teszel a host elé egy router-t (én ezt javaslom, pláne ha később ez publikus neten lesz), vagy csinálsz egy router VM-et, amibe az egyik virtuális kártyán bejön a tényleges kapcsolat, a másik virtuális kártyán meg rákötöd a többi virtuális gép hálózatára. Utóbbi megoldásnál a virtualizációs host hibáival semmit sem tudsz távolról semmit kezdeni, ha a router VM nem/rosszul működik.

Köszönöm, igen időközben már megvitattuk lejjebb, hogy mik lehetnek az alternatívák és egyenlőre a VM-ben futó pfSense-vel barátkozom, bár ezt sem ajánlják.
A Dell szerverben, ami a bare metal server az esetemben van külön dedikált fizikai port publikus ip-vel idrac9 távoli hozzáféréssel, így nem annyira vészes, ha hálózatilag kizárom magam a távolból, marad vészmegoldásnak a távoli terminál. :)

Nem értem pontosan hogyan van az iDRAC bekötve, de az nem arra van, hogy a publikus internetre ki legyen téve, ha esetleg úgy lenne most. Nem arra van a védelme tervezve, hogy állja a netről jövő feltörési kísérlet cunamit.

Az iDRAC-nak (meg bármilyen BMC-nek) jól védett hálózaton kell lennie, amihez távolról csak valami VPN-nel lehet csatlakozni.

Nagyon csábító egyetlen gépet betenni, és azon oldani meg minden funkciót (így a router és tűzfal funkciót is), de tapasztalatból mondom, hogy hosszú távon több bosszúságot és biztonsági rést okoz, mint kényelmet. Ezért írjuk többen, hogy legyen külön fizikai router a virtualizációs host előtt.

Igen, én is féltem először publikus netre tenni, de amióta szerverünk van, így szoktuk csinálni. (kb. 17 éve)
Még kezdetleges Intel szerver BMC is sok éven át kinn volt a neten (IRMM).
A BMC log tele is van sikertelen bejelentkezési kísérletekkel. Szerencsénkre eddig nem volt bajunk belőle. (időnként frissítem a BMC firmware-t is, ha van belőle új)

"hogy hosszú távon több bosszúságot és biztonsági rést okoz, mint kényelmet"
Igen, teljesen igazad van, nem a kényelem az oka. Sajnos gazdasági okai vannak hogy a korábbi 2-3 szerveres működésünket 1db-ra kellett redukálni. Így működünk 2-3 éve már.

( _ventura_ v | 2024. 02. 12., h – 15:11 )

Ahogy írták, erre alapból nincsen megoldás, mert egy hypervisor dolga nem a routeolás NAT-olás, Port forward stb.

Viszon több lehetőség megoldás is lehetséges. 

Első, hogy az XCP-ng elő egy router kerül, így kell egy plusz eszköz, viszont még talán ez a legjárhatóbb (észszerűbb).

Második, hogy az 1 publikus IP az XCP-ng futó router kapja (routeros, openwrt, pfsense stb), és minden más emögött van, maga a hypervisor  managementje is. Ennek előnyével / hátrányával együtt.

Harmadik, hogy a publikus IP-t maga a hypervisor Dom0 kapja, így a port forwardokat NAT-ot is ő oldja meg, persze mivel linux lehet rá tenni DHCP szervert stb. Esetleg a DHCP szerver és többi funkciót már egy VM intézi, így a Dom0 -nak masquerade / portforward kell.

Fedora 40, Thinkpad x280

Köszönöm!

1:ez a szerver egy serverhosting szolgáltatónál lenne elhelyezve, így az első pont nem jöhet szóba sajnos,

2: a második megoldásra melyiket router os-t szokták használni? (a pfSense nálunk céges környezetben a fő router, ami Netgate célhardveren fut. VM alatt is elfogadható lehet a teljesítménye?)

3. a jelenlegi éles szerveren így valósul meg az ipvsadm segítségével. Ahogy nézem, a gyári xcp-ng repo-ban nincs ipvsadm sajnos.

1. Szerverhostingnál miért ne jöhetne szóba ? Amúgy láttam már olyan megoldást, hogy a routert (kis méret) beleszerelték a szerverbe, USB ról kapta a tápot és kész is kifele csak a lógó ethernet látszott ...

2. Amelyik tetszik ismered stb. A legtöbb virtuális router már rendelkezik hypervisor támogatásokkal. A pfsensehez is vannak xen driverek. Viszont a xen-orchestraban lévő HUB teszed fel, akkor már telepítve is lesz guest-utilities. 

3. Hát igen, dom0 nak nem ez a célja, nem erre tervezik tesztelik ...

Fedora 40, Thinkpad x280

Köszönöm, megpróbálom a második megközelítést, és köszi a tippet, még csak addig jutottam, hogy leforgattam a XO-t forrásból az alábbi videó alapján:

https://www.youtube.com/watch?v=fuS7tSOxcSo

És ezek szerint a HUB csak a fizetős XOA-ban érhető el. De gondolom a hagyományos telepítős módon is megoldható a pfSense beszerzése :)

Van ilyen projekt: https://github.com/ronivay/XenOrchestraInstallerUpdater 

Legutóbb már én is ezt használom, bár van még 1-2 hely ahol kézzel fordítom, bár kb 2-3 parancs nem a világ :D

A HUB az ingyenesen is elérhető, csak regisztráció kell hozzá. Nálam mindig fut egy hivatalos XOA kiadás, ami free licences. ott van HUB. Persze felrakható alapból is van, hozzá leírás is meg talán még videó is laurences system jóvoltából ...

Fedora 40, Thinkpad x280

Miért ne lehetne külön router? Nekünk pl. egyik hosting-os rendszerünk úgy van, hogy 1 fizikai router 1U, kettő switch 1-1 U és a négy host 1-1 U. Általában a kis fogyasztású (értsd: nem szerver) eszközöket sokkal olcsóbban lehet elhelyezni ugyan abban a rack-ben.

( x-daemon | 2024. 02. 12., h – 23:27 )

miert nem marad a debian alatti xen?

nftables-el is tudsz natolni.

neked aztan fura humorod van...

Igen, ahogy ventura is emlegette az előnyöket. Vonzók a kényelmes lehetőségek, eddig mindent műveletet parancssorban kellett végezni. Arra gondoltam, hogy a cél-specifikus disztró biztosan jobb, mint amit debian-ban összekotyvasztok. :) Bár igaz, a kotyvasztott is jól működik évtizedes nagyságrendekre visszatekintve is. De ez lehet, hogy a light-load-nak és a szerencsének köszönhető.

Erre én is bedobom a kérdésem: mi a baj a Proxmox-al a Debian-Xen és az xcp-ng+xo helyett? Vagy fordítva, mit ad a "xen stack" egyetlen host esetén, amit a Proxmox nem?

Kapásból meg lenne oldva minden itt felvetett "probléma". Routing+firewall van, host-on port forward és NAT megoldott, kényelmes grafikus kezelés megoldott, jó CLI és automatizált távoli vezérlés megoldott (elég jó és biztonságos az API-ja), profi mentés megoldott.

Semmi baj nincs vele. Debiant használok éles szerver környezetben a kezdetek óta, Proxmox-ot pedig éles intranetes környezetben.
A fő motiváció az volt a kitekintésre az eddig használtak felől, hogy a Dell nem támogatja a debian disztrót az "OpenManage Server Administrator" agent tekintetében.
Igen, másokhoz hasonlóan én is felraktam valahogy régi debian alá annak idején, és újabban már az Ubuntu is felkerült a támogatott disztrók listájára, szóval valószínűleg felrakható a Proxmox alatti debian alá is.
Valószínűleg ki kellene próbálnom. Csak félek, hogy mennyire szabad kirakni a Proxmox-ot publikus környezetbe, nincs tapasztalatom a "hardening Proxmox" témában, mert eddig csak intraneten mertem üzemeltetni.

A Dell teljesen kifuttatja az OpenManage-et, így mára nem releváns, hogy fut-e. A Dell azt mondja, iDRAC-al és iSM-el kezelje mindenki a szerverét OpenManage helyett.

Az annál inkább releváns ezek után, hogy a Dell iSM (iDRAC Service Module) fut-e, és a válasz, hogy sajnos nem, mert Proxmox 8 (Debian 12) és Ubuntu 22.04 esetén már libssl3 van (nincs is libssl1.1), így a Dell által biztosított deb-ek nem telepíthetőek a libssl1.1 függőségük miatt. Proxmox 7 alatt (Debian 11) remekül működik ez a szolgáltatás. Azt nem tudni, hogy a Dell kiad-e és mikor libssl3-mal fordított csomagokat.

Viszont én pl. sosem használtam OpenManage-et. Zabbix-al felügyelek, a Proxmox host-ot telepített agent-el, a hardvert meg iDRAC SNMP-n keresztül. Így az iSM hiánya is csak kozmetikai, mert nem az iDRAC SNMP-n kapom meg a host néhány adatát, hanem közvetlen a host-on futó Zabbix Agent-től.

Nekünk még van pár ügyfélnél Proxmox "direkten" internetre kötve. Azért idézőjelesen, mert az internet egy VM-ben futó OPNsense-re van kötve, és minden azon belül van onnantól. A publikus cím is (akár DHCP, fix IP vagy PPPoE) az OPNsense-n van, a Proxmox csak a fizikai interfészt adja. A Proxmox host, az iDRAC, stb. nem érhető el az internet felől, csak VPN-en keresztül. Az internetről csak az érhető el, amit az OPNsense átenged/publikál. Általában reverse proxy-t futtatunk, ha webes szolgáltatást kell kintről elérni, vagy szükség szerint port forward, ha olyamit kell kintről látni, amit így kell publikálni.

Ezeket is lassan kivezetjük, és a host elé tett fizikai router-rel egészítjük ki az OPNsense-t (azon a magasabb szintű hálózati szolgáltatások maradnak, a tűzfal, route-olás lekerül). Azért, mert ha az egy szem host-tal baj van, akkor a router-re VPN-ezve, a router-be dugott iDRAC-on tudom a szervert menedzselni. Míg ha az OPNsense VM-en át érhető csak el, akkor a host baja esetén elesek az iDRAC távoli használatától.

Szerinem az xcp-ng-t is ugyan annyira nem szabad direkt innternetre kötni, mint a Proxmox host-ot, csak valami tűzfal mögé téve (még ha az egy rajta futó VM is). A hálózati stack-en keresztül azért jóval nehezebb bemenni bárhová, mint IP címen és azon elérhető szolgáltatáson keresztül.

Köszönöm a részletes leírást!
Igen, közben én is elgondolkodtam azon, hogy az enterprise idrac9 esetén mi jelentősége van még az OMSA agent-nek. Köszönöm, hogy felhívtad figyelmem az iSM modul debian 12 inkompatibilitásra!
Én is hasonlót képzeltem el, miszerint egy VM-en futó router OS oldaná meg a port forward / firewall funkciókat és egyben OpenVPN kliens is lenne a telephelyünkön lévő szerverhez, de ez esetben az idrac9 mindenképpen külön kinn lenne az interneten saját publikus IP-vel a tuti távelérhetőség miatt (az idrac-ban lehet szűkíteni az elérést IP-re, maximum ez be lesz állítva, így már hátha nem törhető olyan könnyen..).
Jelenleg haproxy-t használok a webes elérésekhez, ami név alapján dobálja szét különböző VM-ekre a kérést és a Xen dom0-ban van a 80/443 port forward a haproxy VM-re, ezeket a port forwardolásokat akkor átvehetné a dedikált router VM.

A másik megközelítésnél, ahol fizikai router/fw van, milyen eszközt szoktatok használni a Proxmox host előtt?

Köszönöm!

Hát, mi a Mikrotik-et preferáljuk, amit vagy szeret valaki vagy utál (lenéz).

Felhasználási hely és cél függő, hogy melyik modellt. Datacenter-ben lévő gép(ek) elé csak valami CCR-t (dupla táp, tapasztalatunk szerint irtózat kevés műszaki gond van velük), sima kisebb-nagyobb cégnél a telephelyükön lévő szerver(ek) elé meg ami teljesítményben és kialakításban megfelelő (de általában nem a műanyag dobozosakat, hanem legalább a középkategóriát).

Szerintünk ár/érték arányban jók, teljesítményben van olyan modell, ami a mi szükségletünket lefedi megfelelő árért cserébe.

Köszönöm a javaslataidat! A következő kérdésem lett volna, hogy van-e redundáns tápos is, de akkor ezek szerint van. Körülnézek a mikrotik táján.

Egyébként van támogatott telepíthető iDRAC Service Module az Ubuntu 22.04 LTS-hez. Most próbáltam, debian 12 alatt zokszó nélkül települt.
(OM-iSM-Dell-Web-LX-5300-3289_A00.tar.gz)

Aztán hogy működik-e az más kérdés, most csak egy VM-ben próbálkoztam.

Ami mindig is tetszett az XO + xcp-ng ben, (bár valószínűleg ezek (már) megvannak proxmoxban is) A storage xenmotion azaz VPS alatt lévő diskek bármikor mozgathatóak egyik storageról másikra leállás nélkül.

VPS live migrációjához nem kell közös storage sem. Mivel live -ban történik, annyi a kitétel,  van (ha nincsen cpumask), hogy a régiről lehet migrálni az újabb felé (vagy azonos cpu-k). 

Ha migrálni szeretnénk, teljesen más cpu -ra intel -> amd stb akkor van a https://xen-orchestra.com/blog/warm-migration-with-xen-orchestra/ lehetőség, ez minimalizálni a leállást.

Valamint beletettek egy opciót, hogy közvetlen vmware ről lehet átmigrálni https://xcp-ng.org/blog/2022/10/19/migrate-from-vmware-to-xcp-ng/

Fedora 40, Thinkpad x280

A diszk mozgatás és a VM mozgatás működik már Proxmox-on is shared storage nélkül (persze ilyenkor jó soká tart az előkészítés a VM/diszk hosszas másolása miatt).

Annyi a Proxmox "hátránya", hogy csak az Ő általa kezelt cluster-be léptetett node-ok között tudja ezt megtenni (az inter-cluster migráció fejlesztés alatt áll a roadmap szerint, arról nem olvastam, hogy szólü node-ok között terveznének ilyent megvalósítani). Az XO pedig egymástól független host-okkal is meg tudja ezt csinálni (tudtommal, nem használom).

A CPU eltéréseket a Proxmox úgy kezeli, hogy a Qemu több standardizált CPU-t támogat (különböző elérhető utasítás kiterjesztésekkel), és ezek közül választva különböző CPU-val szerelt host-ok között is mozgatható a VM (akár Intel-AMD viszonylatban), amennyiben az adott utasításkészlet-csomagot mindkét CPU támogatja. Persze ez is csak cluster-en belül.

Én úgy látom, a Proxmox helyben futó node-ok cluster-be szervezésére van felkészítve, és nincs egyenlőre megoldásuk különböző helyeken lévő node-ok vagy cluster-ek központi kezelésére. Míg az XO ezen a magasabb szinten működik, ahol is madártávlatból lát mindent, és azon belül tud node-okat és cluster-elket kezelni, akár egymástól függetlenül, központosítva.

De mivel itt egyetlen host-ról van szó, én részemről az all-in-one Proxmox-ot kényelmesebb megoldásnak látom, mit az xcp-ng, plusz kézzel fordított XO beüzemelése, azért javasoltam.