Automatikus port forward NAT -olt hálózat routerén

Linux-haladó

A következő problémával fordulok hozzátok.

Adott a következő hálózati felépítés:
 

                                                                      +--------------------+
+------------+                                    +---------+         |                    |
|            |                                    |         |         |  Machine 1         |
|            |                                    |         |    /-----                    |
|            |         +--------------------+     |         -----     |                    |
|            |         |                    |     |         |         +--------------------+
|            |         |     Router         |     |         |                               
|    LAN2    |    /-----                    -------  LAN1   |                               
|            -----     |                    |     |         |         +--------------------+
|            |         +--------------------+     |         |         |                    |
|            |                                    |        ------     | Machine n          |
|            |                                    |         |    \-----                    |
|            |                                    |         |         |                    |
|            |                                    +----|----+         +--------------------+
+------------+                                         |                                    
                                                       |                                    
                                         -             |              +--------------------+
                                                       |              |                    |
                                                       |              | net-infra          |
                                                       +---------------                    |
                                                                      |                    |
                                                                      +--------------------+

A probléma pedig az, hogy a LAN1 -en dinamikusan megjelenő kliensek (Machine1 - Machine n) elérhetőek legyenek LAN2 felől, úgy hogy Router NAT -ol LAN1 -ről LAN2 -re. LAN1 és LAN2 privát IP címeket használ.

További adatok:

  • Router valójában egy Proxmox host.
  • Machine 1...n pedig Proxmox VM -ek és konténerek.
  • LAN1 egy "virtuális" hálózat, csak a Proxmox host -on létezik. (Egy nem bridge -elt network ifc.)
  • LAN2 irodai lokális háló, rajta egy tucat kliens (notebook, etc.). Vannak kliensek akik LAN2 -re VPN -en jutnak el.
  • net-infra: allways on CT ami a DHCP -t és DNS -t adja LAN1 -nek. (alpine + dnsmasq)
  • Sajnos a NAT kötelező LAN2 korlátozásai miatt. (Csak engedélyezett MAC lehet rajta.)
  • Mind LA1 és LAN2 megbízható. Nem elsődleges cél a biztonság (nyilván publikus szerver ne legyen a megoldásban).

Amit próbáltam, illetve ötletek:

  • Fellőni egy VPN szervert -t net-infra -n. Ez kapna egy statikus port forward -ot. Így LAN2 felől VPN csatlakozás után az összes Machine elérhető. Itt a LAN2 -es kliensek konfigja a probléma. Nem biztos, hogy IT örülne a VPN kliensek telepítésének. Továbbá egy sor kliens dupla VPN -en kellene csatlakozzon.
  • UPNP-IGD szerver Router -en, + upnpc a Machine -eken. Sajnos az egyetlen épkézláb Linux -os szerver (MiniUPNP) szűri a privát IP címeket, és nem hajlandó portot nyitni. Megfoltozhatnám a kódot, de ha lehet ezt egyelőre nem tenném. Hátrány, hogy az upnpc minden Machine számára kötelező a minimális SSH eléréshez is.
  • Valami SSH alapú megoldás. Router -en futna egy korlátozott parancshalmazra limitált SSH szerver. A kliensek itt adnának ki port open parancsokat.
  • Az előző SSH -s megoldás, de a port nyitást "net-infra" kezdeményezné amennyiben a dnsmasq szkriptelhető ennyire. Ennek előnye, hogy a Machine -oknak nem kell spéci konfig.
  • LXC hook Router -en. Ez képes lenne CT vagy VM indításnál portot nyitni. Sajnos nem tudja net-infra által kiosztott IP címet. További nyűg, hogy új CT/VM kézi konfigurálást igényel.
  • Router -re átteni a DHCP + DNS -t funkciót, és itt szkriptelni a DHCP -t port kezelésre.
  • Valami "port knocking" szerver Router -re. Nem néztem még milyen implementációk vannak erre (pl openwrt mit használ?). Arra gondolok amikor valamilyen port -ra érkező kommunikáció hatására a router portforwarding -ot konfigurál.
  • [szerk.] NAT nélküli route -olás by PunishR: ez sajnos nem járható út, mert pl. a VPN -es gépek esetén több router -en keresztül kellene route -olni, és ezek konfigját nem tudom állítani. Szóval ez csak LAN2 -re diretbe kötött gépekkel menne static route -esetén, a a dinamikus rout -olás meg tul bonya.

Ki milyen lehetőséget lát a probléma megoldására? Van esetleg valaki aki csinált már ilyet?

[szerk]
Elfelejtettem leírni, hogy nem én vagyok a céges IT :), gyakorlatilag árnyék infrastruktúrát építünk, hogy megönnyítsük a saját életünket (firmware fejlesztők vagyunk). Jelenleg "Router" egy Linux -os szerver, amit többen használunk. A globális konfiggal néha egymás lábára lépünk, így szeretnénk mindenkinek saját játszóteret. Sajnos a gépnek LAN2 felé továbbra is egyszerű workstation -nak kell lennie, csak a belét alakíthatjuk át. Ha az IT -hoz mennék ilyen-olyan igényekkel, először azt kellene elmagyaráznom, miért jó ez, és miért nem dolgozunk máshogyan.
 

  • 700 megtekintés

( PunishR v | 2022. 09. 06., k – 20:27 )

Ezt a "kotottseget" gondold at megegyszer,
"Sajnos a NAT kötelező LAN2 korlátozásai miatt. (Csak engedélyezett MAC lehet rajta.)"
es routeolj... NAT nelkul

Ez működhet, bár azért az nehézkes, hogy hogyan fog működni oda-vissza, ha más subnetek felé az átjárás egy teljesen másik routeren van. Akkor LAN2 gépei hogyan és merrefelé route-olnak? Ez akkor lehet jó ötlet, ha a router egy lábát tudod "berakni" a virtualizált subnetbe.

Tényleg, erre nem is gondoltam! Hiába, lelkes amatőr vagyok csupán 😅

Ami kihívás lehet:

  • A LAN2 és az "arrafelé" lévő egyéb hálózatok IP tartományával IP ütközés. Ezt mondjuk traceroute -tal ki tudom tapogatni.
  • Az ismeretlen számosságú routerek LAN2 -n túl tudják merre találják LAN1 -et. Bár ez talán nem is gond, hiszen "Router" LAN2 "lábát" most is megtalálom. Elég lehet a kliens gépekre egy megfelelő route bejegyzés.
  • A LAN2 és azon túli routerek hajlandók legyenek továbbítani az "ismeretlen" IP range csomagjait.

Ez ígéretesnek hangzik, kipróbálom. Köszi!

Én annyival kiegészíteném, hogy ezesetben a Proxmox-ot LAN2 default router-ével linkelném össze egy független, 3. VLAN-on (PTP, 2db IP), így a klienseket nem kell piszkálnod, ők default gw felé mehetnek, azon meg definiálsz minden egyéb forgalmi irányt.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Másnap, tiszta fejjel végig gondolva, ez nem fog működni, illetve max LAN2 és LAN1 -re direktbe feldugott gépeken. Ha 1 -nél több hop kell, akkor a 2. router -től kezdve, valahogy meg kell tanítani router -eket merre találják az én hálózatomat.

  • Sajnos a céges router -eket nem tudom konfigolni, thehát static routeing kilőve.
  • A dinamikus routing pedig kockázatosnak tűnik és bonyolult is szóval ezt inkább nem. Amúgy is feltételezem, hogy a router -ek nem fognak beszélni random új belépőkkel, azaz a rendszergazda nélkül amúgy sem fog menni.

Bár jol nézett ki elsőre, de ez nem fog menni.

 

(ja, dinamikus routeinghoz is kell konfolni a hálózati eszközöket)

És teljesen esélytelen, hogy az IT segítsen neked? Azért nem tűnik egy olyan elborult dolognak, hogy a vmek elérhetőek legyenek a belső hálózaton, és ez alapvetően egy egyszerű routeolási kérdés. Tényleg jó a cégnek, hogy mindenféle bonyolult megoldásban gondolkozol emiatt?

Illetve ha egyébként jó az ssh portforward, akkor tényleg nem elég, hogy mindenki megírja magának az ssh klienshez a portforwardokat, aztán csoki? Akár egyszer le is generálhatjátok, ahol simán taplóparaszt módon be van égetve, hogy mittomén a 60001-60255 a megfelelő lan1.1 - lan1.255 22es portjára van a forward, aztán csoki?

A static port tartomány -> ip:port tartomány mappaing is jó lehet. A "mindenki megírja" részt szeretnénk kihagyni ha lehet. C fejlesztők vagyunk, egyáltalán nem triviális, hogy mindenki rendszergazda is legyen. Illetve minél kevésbé kell a "rendszergazdának" átmenni DevOps -ba annál jobb. Szeretnénk ha egyszer kellene időt fektetni a Poxmox -ba, és utána next-next-finsh lenne a CT -k és VM -ek menedzselése.

A jelenlegi linux szerverbe fel évente egyszer kell belerúgni, amikor a kedves felhasználók felzabáljak a szabad helyet, vagy valaki valami globális cuccot eltör (pl. Python 3.8 upgrade azt lehat minden szkript ami nem bírta). Van a szerveren docker, csak nem divat használni, illetve sokan nem értenek és nem akarnak érteni hozzá.

Szóval be szeretnénk dobozolni az embereket valami egyszerű megoldással. Továbbá van még pár levetett desktop gép, jó lenne ha "cluster" -ben lennének, és ott indulna a CT/VM ahol kicsi a load. A proxmox tud ilyesmit, de ennek még utána kell nézzek. Ha túl bonya lesz, mindenki kap majd "gépet" minden szerveren, azt majd válogat hol akar dolgozni éppen (és szinkronizál ahogy tud). Vagy skálázni lehet alkalmazás szinten is (jenkins + jenkins slave, distcc, sccache, stb...). Álmodozni marhára tudunk, de a józan ész (egyelőre) erősebb.

Hát, nem vagyok meggyőződve róla, hogy a proxmox kevesebb törődést igényel. Pláne, ha automatán migráló és skálázódó clustert akarsz építeni.

Megnéznem a helyedben esetleg a teleportot, bár lehet, hogy ágyú-veréb: https://goteleport.com/

esetleg arpi_esp container-sshját, lehet, hogy pont elég arra, hogy kordában maradjanak azon a linux szerveren a userek. https://github.com/containerssh/containerssh

A mindenki megírja azért kb a portforward megértése, nekem viszonylag extenzív tapasztalatom van ezügyben, egy két elkeserítő indiai esetet kivéve, ez szokott sikerülni.

Ill én még továbbra sem vetném el (már a lentire reagálva), hogy beszélj az ITval. Azt értem, hogy ezt nem üzemelteti nektek, de azért az egyáltalán nem biztos, hogy visszük mi, csak légyszi kapjon a LAN1 egy tartományt, ami le van routeolva, meg mondjuk nekünk tűzfalazva, az ne menne, sokkal kevesebbet kér enni, mint egy új szolgáltatás.

Megnéznem a helyedben esetleg a teleportot, bár lehet, hogy ágyú-veréb: https://goteleport.com/

Első ránézésre nem vágom mi ez, és mire lenne nekünk jó, de majd később kicsit utána olvasok.

esetleg arpi_esp container-sshját

Igen, ez nekem is eszembe jutott. Nem tudom azt tudja e ami nekem kell. Én nem bezárni szeretném a felhasználót, hanem elszeparálni, több szabadságot adni neki egy esetleges "ütközés" kockázatának csökkentésével. A Proxmox a web UI -jal egyszerűvé teszi a konténer készítést, és menedzsmentet, lecsökkenti a betanulási időt.

Első ránézésre nem vágom mi ez, és mire lenne nekünk jó, de majd később kicsit utána olvasok.

Alapvetően egy ssh auth gateway megoldás, amivel jól el lehet érni infrastruktúra elemeket. Lehet, hogy segítene a portforwardok kialakításában is. Részleteiben nem ismerem a cuccot, csak gondoltam beteszem ide.

Igen, ez nekem is eszembe jutott. Nem tudom azt tudja e ami nekem kell. Én nem bezárni szeretném a felhasználót, hanem elszeparálni, több szabadságot adni neki egy esetleges "ütközés" kockázatának csökkentésével. A Proxmox a web UI -jal egyszerűvé teszi a konténer készítést, és menedzsmentet, lecsökkenti a betanulási időt.

Alapvetően azért jutott eszembe, mert ránézésre elég lightweight, ugyanúgy sshzni lehet mint eddig, cserébe transzparensen megoldja a "nem szokás használni a dockert" kitételt, szóval kb out of box adja neked a szeparációt, hogy mindenki csinálhasson a kis szemétdombján, amit akar, tegyen bele új python, pipelje orrba szájba, vagy bármi. Azt mondjuk nem tudom, hogy az hostra dugott hwk expozolásával hogyan bír el, de mondjuk ott gondolom a proxmox is igényel szeretetet (igaz, ott lesz gui asszem, ami segít). 

( ricpet | 2022. 09. 06., k – 20:28 )

Mi olyan megoldást találtunk, hogy bridge networking a virtualizációban, és a switchen arra az egy portra, amin a virtualizáló host van, kértünk felmentést a szabály alól, hogy csak fixen egy engedélyezett MAC cím lehet jelen. Persze ez inkább csak egy workaround abba az irányba, hogyan lehet ezt egy értelmes kompromisszummal üzemeltetni. És ez még egészen vállalható, ha tényleg megbízható hálózati szegmensekről beszélünk.

Az én esetemben is ugyanez volt. De pont ezt is írtam, hogy nem én csináltam meg ezt a konfigot, hanem megkértük az IT-t, hogy adjanak egyetlen switch port esetén felmentést, és vélhetően mivel értelmesen és elfogadhatóan érveltünk, ezért meg is csinálták.

( zrubi v | 2022. 09. 07., sze – 12:52 )

gyakorlatilag árnyék infrastruktúrát építünk, hogy megönnyítsük a saját életünket

A céged meg várhatóan kib*tt sok pénzt költ arra, hogy az ilyeneket felderítsék/megakadályozzák....

 

Én ezt az erőfeszítést inkább értelmes irányba javasolnám tájolni, semmiképp sem a 'shadow IT' felé.

zrubi.hu

Igazad van de ;) :

  • vékony a határ, hogy a mi melónkhoz nem értő IT és DevOps csapatok meddig tudják az igényeinket kiszolgálni. Pl. board farm -ot nem fogunk magunknak építeni, de szeretnénk a "szerverre" feldugott embedded eszközöket használni. Ezt egy IT vagy DevOps menedzselte pl. AWS instance nehezen oldja meg.
  • Az IT és a DevOps csapatunk istencsászár, csak 10 -ed annyian vannak mint amennyien kellene hogy legyenek. Így egy official "VM/CT szerver" szolgáltatása részükről a közeljövőben nem megoldható.
  • Addig amíg a "szarjaimat" az IT/DevOps nem kell menedzselje, csak a saját munkaidőm a veszteség. A Proxmox azért lesz, hogy hatékonyabbak legyünk, hosszabb távon akár kifizetődő is lehet. (pl. 1 nap build environment set-up|upgrade, vs. nesze egy "gép" ahol megvan minden.)

Nyilván más a kockázata egy ilyen "szerver" kiesésének a zökkenőmentes munka tekintetében, de nem sokkal rosszabb mint az amúgy is fejlesztők által menedzselt laptopok. (A fejlesztői cuccokat mi menedzseljük a gépen, az IT adja az alapokat (gép, OS, víruskereső, VPN, stb...). De pl. noetbook backup nincs, mondván van OneDrive meg git szerver, dolgozz oda. Azért mi a csapatban backup -olunk is.)

Olyanon nem gondolkoztatok, hogy elmentek egy olyan céghez dolgozni, aki a munkátokhoz szükséges erőforrásokat adja és nem magatoknak kell összebarkácsolni?

Vagy azon elgondolkoztatok, hogy ha most megoldjátok okosba, és beválik, akkor megnyertétek, hogy onnantól ingyen, kötelező jelleggel így kell csinálni a jövőben?

A kérdésre válaszolva én LAN2-ben "kinéznék" néhány nem használt IP címet (nem tudom hogyan megy az IP cím foglalás nálatok), és azokra 1:1 NAT-olnék a LAN1-ből. Így nem kell sehová plusz route, nem lesz több MAC cím LAN2-ben, stb.
Ezt akár úgy is beállíthatod, hogy mondjuk 10 cím-pár között fixen működik az 1:1 NAT, és a LAN1 oldalon vagy van épp valami, vagy nincs, ezt a felhasználónak kell tudnia (de nyilván tudja majd valakitől, ha elérhetővé válik a VM, amit használni szeretne).

Olyanon nem gondolkoztatok, hogy elmentek egy olyan céghez dolgozni, aki a munkátokhoz szükséges erőforrásokat adja és nem magatoknak kell összebarkácsolni?

Mindig vannak határok. Van a cégnek IT és DevOps csapata is, de van még hova fejlődni. Nagyon sokféle projekt van, a szolgáltatás rétegig még kis költséggel lehet konszolidálni a rendszert (HW, virtualizáció, szolgáltatások: jenking, gerrit, gitlab, etc...). Ami e felett van az már borzalmasan fragmentált, és erősen projekt specifikus. Erre a részre nincs dedikált csapat, itt mindenki magának kókányol. Összességében sok mindent megkapunk már így is, az alkalmazásréteg konszolidációján meg dolgozunk. Azon is, hogy legyen igazi DevOps mert a mostani DevOps inkább egyfajta engineering fókuszú üzemeltetés. Lehet, hogy a menedzsment is ebbe az irányba szeretne haladni, és ezért a névválasztás, csak ezek lassú folyamatok.

A Proxmox cluster mondjuk pont lehetne IT feladatkör. Ha beválik majd betámadom a menedzsmentet és áttesszük IT feladatkörök közé. De prototípus nélkül nem igazán tudok érvelni mellette. Ha fut, és segít, akkor könnyebb mondani, hogy nézzétek, milyen klassz, ha lenne rá rendes support meg maintenance (és nem dzsunka PC -ken menne) biztonságosabban üzemelne a cég.

Vagy azon elgondolkoztatok, hogy ha most megoldjátok okosba, és beválik, akkor megnyertétek, hogy onnantól ingyen, kötelező jelleggel így kell csinálni a jövőben?

Ettől nem félek. Elsősorban azért csináljuk mert érdekes :) Innen onnan lepottyanó töredék időkben dolgozunk ezen (pl: https://xkcd.com/303/).

LAN2-ben "kinéznék" néhány nem használt IP címet

Ezt én kockázatosnak érzem, vannak itten mindenféle varázslatok. Pl. a nem az IT konfigurálta IP tartományra szóló ARP kéréseket megeszi valami a LAN -on. A gépből kimegy az ARP, de a másik gépre már nem érkezik meg. Nem akarnék az IT lábára lépni egy jókis IP ütközés összekendácsolásával.

Milyen értelemben?
Az biztos, hogy csak regisztrált MAC címmel kapnak a gépek IP -t a hálózaton. Lehet a switch elég okos, hogy ő szűrjön, akkor meg akár az ARP -t is értheti.

Nyilván van esély rá, hogy tévedek, mert hub -om, vagy port mirror képes switch -em nincs, abból főzök amint a tcpdump mond.

( zeller | 2022. 09. 08., cs – 11:50 )

Az "elérhető legyen"-t picit részletesebben fejtsd ki. Hány port, milyen forgalmak, lehet-e portot átírni a natbox-on és hasonlók. Mert ha lehet, akkor kell egy olyan szabálybázis, ami a natbox (router) LAN2-es címére és adott portra/porttartományra érkező kéréseket dnat-tal átdobja a proxmox-os megfelelő IP-címen lévő portra. Ez "szépen" kimatekozható, hogy milyen 1:1 megfeleltetés legyen úgy, hogy ütközést ne okozzon.
Mivel ez tisztán csomagszűrőben megoldható, így egyszer be kell toltni az 12345 rule-t, és utána ha megy mögötte az adott címen egy vm, akkor betalál a csomag, ha nem, akkor nem...

Az "elérhető legyen"-t picit részletesebben fejtsd ki.

Jogos. Jelenleg "Desktop Linux" jelleggel használjuk a gépet. Fel van rá dugva pár beágyazott eszköz az egyik csapatnak. Más csapatok emulált eszközökkel dolgoznak. Az emberek zöme SSH -val lép be, és terminál -ban dolgozik, de vannak akik VNC -znek és távoli asztalon dolgoznak.

A szükséges minimum egyetlen SSH port minden machine -nek. SSH tunnel -lel megoldható a többi port, ha szükséges. De minél nagyobb a szabadság, annál jobb.

Mert ha lehet, akkor kell egy olyan szabálybázis, ami a natbox (router) LAN2-es címére és adott portra/porttartományra érkező kéréseket dnat-tal átdobja a proxmox-os megfelelő IP-címen lévő portra.

Igen, igen, ez van most. A baj az, hogy új CT -nek vagy statikus IP -t adunk amit kézzel kell állítani, vagy kapnak címet DHCP -n. De a statikus port forward miatt MAC->IP hozzárendelés kell ami megint csak kézzel állítgatós. A kézzel állítás meg könnyel elrontható. Ha a CT meg tudná oldani magának a network konfigot akkor könnyebben menedzselhető a rendszer.

Valószínűleg az lesz a megoldás, hogy átrakom CT -ből a host -ra (router) a DHCP+DNS szolgáltatást, és írok egy szkriptet, ami DNS/DHCP változás esetén fut le, a domain név alapján kibányássza a PVE konfigból CT/VM ID -t, majd a DHCP -ből kinyert IP alapján megcsinálja a port forwardot. Így automatizálva lesz a <router LAN2 IP>:<CTID + port> -> <machine LAN1 IP>:port forwardolási séma.
Még az is megoldható, hogy ha router LAN2 IP -je változik akkor frissítsem a meglévő bejegyzéseket (mert sajna az bezony dinamikus).

A baj az, hogy ha valakinek nem elég az SSH, akkor körülményes a konfigurálás, illetve a rendszergaza nélkül nem is igazán lehetséges. Persze felvehetnénk valami key-value store -t, ahol lehet userként új portot felvenni, de ez már nemileg túlzás.

( Elbandi v | 2022. 09. 08., cs – 21:05 )

ha N szama kicsi, es nem nagyon valtozik, akkor en felvennek N alias ipt a proxmox hostra (aliasok macje azonos, szures pipa), majd egyenkent SNAT+DNAT-olnam a gepeket. 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!