NAT, publikus IP-k, local IP tartományok, routing probléma Proxmox VE7 alatt

Linux-haladó

Sziasztok!

Az itt leírtak alapján működik most a hálózat. Proxmox VE 7.
A NAT-olás a következőképpen működik:

[...]
iptables -t nat -A PREROUTING -d $egyik_publikus_IP/32 -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.4.2:22
iptables -t nat -A PREROUTING -d $masik_publikus_IP/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.6.2:80
iptables -t nat -A PREROUTING -d $masik_publikus_IP/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.6.2:443
[...]

1. probléma: bármelyik VM egy másik VM publikus IP-jén, vagy domainnéven keresztül nem elérhető, csak ha a /etc/hosts, vagy Windows alatt a C:\Windows\System32\drivers\etc\hosts fájlba beírom a domainhez tartozó local IP-t (hosts poisoning).
Pl. Windows alatt böngészőből nem tudok megnyitni egy ugyan ezen a szerveren, de másik VM-ben futó weboldalt, amely a külvilág felől elérhető, csak ha beírom a hosts-ba:

192.168.6.2 valami.tld

2. probléma: a belső IP tartományok nincsenek elszeparálva egymástól. Hiába a /24 az egyes vmbrX beállításaiban, a VM-ek belső IP alapján elérik egymást.
PL. a SAMBA megosztások IP alapján bármelyik VM-ben felcsatolhatóak, vagy a 192.168.6.4 IP-ről simán be tudok SSH-zni a 192.168.3.7-re, holott elméletileg más hálózat kellene, hogy legyen, mindkettő /24 maszkkal.

Segítenétek megoldani ezeket a problémákat?

  • 316 megtekintés

( mauzi v | 2022. 02. 23., sze – 12:49 )

1. probléma: nézz utána a hairpin NAT-nak.

2. probléma: az iptables FORWARD szabályaidat nem ismerem. Feltételezem, hogy minden irányban átengeded velük a forgalmat, nem csak a WAN kapcsolat irányába.

Itt jól leírja a problémámat.
Azt szeretném, hogy pl. a 192.168.5.0/24 hálózatban lévő VM-ek továbbra is elérjék belső IP-n keresztül IS egymás szolgáltatásait ÉS a publikus IP-n keresztül is.
Viszont a 192.168.4.0/24 csak publikus IP-n keresztül legyen számukra elérhető

Írnál esetleg példát, mit kellene csinálnom?

Egyelőre nincs semmilyen FORWARD szabály.
Írnál a fenti példáim alapján egy mintát, FORWARD szabályra?
 

A /etc/iptables/rules.v4 tartalmazza az eddigi szabályaimat.
:FORWARD ACCEPT [1370822:544450924]
van csak benne eddig, meg a nat PREROUTING szabályok

( _ventura_ v | 2022. 02. 23., sze – 15:15 )

Mai napig állítom, hogy a hypervisor ne foglalkozzon semmi mással csak a virtualizálással, meg az azt kiszolgáló minimális api-val.

Nahh de a lényeg, ha van is ilyen akkor azt, mindig ugy oldom meg, hogy a hypervisorba felhuzok egy virtualis routert van pár (CHR,openwrt,vyos sbt). És MINDEN hálózati funkciót az lát el és kész. Éretelemszerűen, ha lehetséges a hypervisor nem csak ide van "visszahurkolva" hanem van független managementje is.

Fedora 42, Thinkpad x280

( GaLbi | 2022. 02. 23., sze – 20:49 )

Szerkesztve: 2022. 02. 23., sze – 20:49

egy-két észrevétel:

1, ha nem tudsz feloldani névre egy ip-t, és kézzel kell mókolni a hosts fájlókat, akkor ott rendbe kell tenni a DNS szerver illetve környékét. A DNS szerver mondja azt meg, hogy adott névre milyen IP-t kapjon vissza a kliens. Az, hogy ez egy belső vagy külső IP legyen a beállításoktól függ. (Ha külső IP-n akarsz valamit elérni, akkor lehet, hogy szükség lehet harpin NAT-ra) 

2, nem ismerem a Hetzner, és nem vagyok PROXMOX guru, de Én is hibásnak tartom ezt a koncepciót, hogy a PROXMOX hoston alakítod ki a hálózatokat, mert ilyenkor ott kell szűrést illetve a hálózatok szeprációját is megoldani.

Ahogy már megírták a legjobb megoldás az lenne:

- a PROXMOXNAK van egy belső IP címe (management)

- van egy tűzfal/router (OPNSENSE-t javaslok) ami megkapja a külső IP címeket, illetve vannak belső lábai, szegmensei, ami felé NAT-tól. Ebben az esetben egy helyen menedzseled az IP forgalmat, és itt egy helyen tudod a szegmenseket szeparálni, DNS-t hangolni. 

Nem kötözködés, csak inkább kíváncsiság:

de Én is hibásnak tartom ezt a koncepciót, hogy a PROXMOX hoston alakítod ki a hálózatokat

Mégis hol alakítanád ki a hálózatokat? A Proxmox egy felület olyan, már rég óta létező technológiák felett, mint pl. LXC konténerek, KVM virtuális gépek, IPTABLES/EBTABLES alapú tűzfalak, "brige"-ek, "bond"-ok, de akár még VXLAN-ok is konfiugrálhatók rajta keresztül...

A Hetzner-nél kapott egy gépet, egy publikus IP-vel amin most Proxmox van és abból virtualizál, arra van route-olva az extra /29 amit vett...

Persze lehetne egy OpnSence VM-en keresztül tolni az egészet, igaz... Én csak nem vagyok benne biztos, hogy az SOKKAL jobb lenne...

Láttam már olyant is, ahol a proxmox-ra HaProxy van rakva és automatikusan osztja szét a terhelést a belső háló felé...

De győzz meg :D

Debian Linux rulez... :D
RIP Ian Murdock

Nálunk vannak arista switchek amik kb linux, szóval tehetnék rá X-et gnome-shell-t stb de minek ? Az a dolga, hogy a csomagokat továbbítsa. 

A hypervisor dolga a VPS ek futtatása, nem webszerver/sql server, packet filtering, NAT stb megvalósítása. Persze csinálhatja, viszont ez mind hypervisortól vesz el erőforrást, és értelemszerűen minden mást is.

Arról nem beszélve, hogy egy komplett router/tűzfal rendszerben jóval több lehetőséged van mint bármelyik hypervisorban lévő megoldás. Ezért mondom, ha kell network stack, azt ne a hypervisor futassa már, hanem dedikáljunk neki rendes VPS-t. 

Fedora 42, Thinkpad x280

- ennek legföbb oka a biztonság, mert ha megtörik a hypervisort, akkor minden VM-hez hozzáférnek. 

- minimalizáljuk azokat a szolgáltatásokat, amik a hypervisoron futnak, mert azokat nem lehet mozgatni egyszerűen a hypervisorok (fizikai gépek) között, miközben vm-t simán migrálok egyik helyről a másikra. Ha jól van kialakíva a hálózat, akkor senki nem vesz észre semmit a mozgatás alatt.

- mivel Linux alapú, ezért mindent is fel lehet rá telepíteni, egészen a következő frissítésig, és utánna megy a fejvakarás, hogy miért nem megy az upgrade a következő verzióra. Ezeket Én éppen ezért kerülném