Virtuális gép (lxc) public IP címe (bridge)

Virtualizáció

Üdv!

Van egy kis szerver, amin fut több virtuális gép (Fc31). A gép NIC bridgelt-ként van beállítva és minden lxc konténer hál.interfésze ehhez van kötve. Így a fizikai és az lxc konténerek egy NIC-en érhetők el. Szépen megy is évek óta. Pl.:

hoszt: 10.10.10.201

lxc1: 10.10.10.202

lxc2: 10.10.10.203  ...stb.

 

Helyi hálózatban van a gép, csak itt használjuk. De most átmenetileg az egyik lxc-t ki kellene tenni a netre (a többi nem is érdekes most). Van publikus IP címünk. Elég csak az adott vm-nek (pl. lxc2) átállítani az IP címét a publikusra? A virtualizáció miatt nem keveredik semmi elvileg...(?)

(Egy másik fizikai szerver működik is egy másik publikus IP címmel. Emellé kellene ez átmenetileg.)

  • 223 megtekintés

( Swifty v | 2020. 03. 20., p – 10:48 )

Nem egyszerűbb csak "beNATolni" egyes portokat a publikus IP-ről a belső hálóra?

Debian Linux rulez... :D
RIP Ian Murdock

( ggallo | 2020. 03. 20., p – 11:05 )

Ha csak az IP címet állítod át publikusra attól nem válik elérhetővé a VM internet felől. Ha meg azt a hálózati kártyák kiteszed az internetre "fizikailag", akkor a neten lesz az összes VM (és a host is) a címétől függetlenül.

Az előttem szólóhoz csatlakozva, a tűzfalon/internet router-en kell végződtetni az adott publikus IP címet, és akár 1:1 NAT-tal megoldani a kapcsolatot (vagy ami még inkább  üdvös lenne, csak a szükséges portokat átirányítani belfelé irányban).

Én egy szóval nem említettem, hogy plusz egy router-t kell beteni, ez félreértés lehet.

Nyilván most sem a konténereket futtató gép van kirakva a publikus internetre fizikailag (vagy legalábbis nem az az interfész, amin egyébként a belső hálózatos forgalom is megy), van már előtte legalább egy router/tűzfal. Én azt írtam, azon kellene a megfelelő port átirányítással a szükséges publikus IP címre érkező forgalmat a belül lévő konténerre juttatni. Az ehhez szorosan kapcsolódik, hogy visszafelé meg ugyan azon a publikus IP-n kell kiküldeni legalább a válaszokat, de ez is a router dolga.

Abban az esetben lehet a konténerre közvetlen beállítani a publikus címet, ha ez ott bevett gyakorlat, és ki van alakítva erre a címzés és a megfelelő belső hálózati szeparáció (mondjuk van saját publikus tartományuk oda router-olva, és a saját router abban a gateway egy lábán, és bizonyos gépek/VM-ek/konténerek külön fizikai interfészeken erre a publikus címeket használó szegmensre vannak kötve - ez egy felállás a sok közü). Meg persze a konténerben a megfelelő védelem. Különleges esetben ez persze mehetne úgy is, hogy a publikus és a belső forgalom egy fizikai interfészen, de külön VLAN-okban zajlik. Műszakilag. De ilyent szerintem éles rendszeren nem csinál senki.

( airween v | 2020. 03. 21., szo – 19:35 )

Nem ismerem a Fedorát, de az amúgy biztos, hogy a hálózati (fizikai) NIC a bridge interface? Jólnevelt LXC általában felhúz valami saját bridge interface-t (pl lxcbr0), így ha ez a helyzet, akkor hiába állítod át a konténerben az IP-t, az nem fog működni.

Ha nem ez van, én akkor sem bontanám meg a rendszert, inkább NAT.

Több mint egy éve használom. Simán működik a bridge (ahogy más disztribekben is), pl.: https://jfearn.fedorapeople.org/fdocs/en-US/Fedora/20/html/Networking_G…

Így a bridge NIC-hez (br0) kötött interfészek és látszódnak a fizikai kártyán a hálózatban, több IP címe van a gépnek. Az LXC-ben az alapértelmezett lxcbr0 (ill. esetleg virbr0) helyett ezt a br0 interfészt kell beállítani.

Az lxcbr0 nem elérhető kintről (LAN-ból sem) nyilvánvalóan, a hosztgépen kell átírányítani a megfelelő portokat. Én a másik megoldást választottam, persze a konténereken is fut firewalld.

(NM is kezeli a bridge interfészt.)

 

Az eredeti problémát megoldottam másképp, egy Cloud VPS-re kitettem a dump-ból a szükséges szolgáltatás(oka)t.