Az alábbi "beugró" feladat gyors megoldására képes kollégát keresnénk a subj-ben szereplőek szerint.
Adottak webszervert linuxon futtató kliensgépek NAT mögött.
Adott egy központi, pulic elérhetőségű linuxos webszerver adatbázissal.
A feladat olyan kód írása a kliens-gépekere és a központi webszerverre, hogy a központi webszerverre bármilyen platformon, bárhonnan böngészővel bejelentkező userek, felhasználónév/pass azonosítás alapján elérjék a nekik engedélyezett kliensgépek webszerverét.
Papírok, iskolai végzettség nem követelmény, csak a célhoz elégséges tudás és ismeretek.
- 3318 megtekintés
Hozzászólások
user/pass után megfelelő redirect és arra reverse proxy a NAT-olt hálón ülő webszerver(ek)re?
milyen modon kellene elerniuk?
tehat valami azonositashoz kotott mod_proxy-rol/mod_backhand-rol beszelunk a public szerverre, es kivulrol erkezo kereseket kellene csak tovabbdobalni a NAT-olt halora jogosultsagtol fuggoen, vagy mindenfele forgalmat kellene proxyzni(nemcsak az apache-okat kell elerni, hanem tavoli ssh, satobbi)
Tyrael
Kedves STP és Tyra3l!
Ha pontosan érteném, amit kérdeztek, akkor én oldanám meg a feladatot :)
Az én bikkfanyelvemen: A probléma, hogy a kliensgépek olyan belső hálón vannak, ahol 2-5-100 ip eszköz "megy ki" ugyanazon 1 public cím alatt, és a NAT routerhez nem férünk hozzá, tehát port forward, stb. felejtős. A NAT mögötti kliensgépek egyik első ténykedése bootolás után, hogy bejelntkeznek a központi szerverre, és kiépítenek egy adatkapcsolatot. Ennek segítségével ha egy user bejelntkezik a központi gépre, akkor a server képes őt "forwardolni" a NAT mögötti kliensép webszerverére, és úgy használhatja, mintha a belső hálóján csücsülne és pl. belső ip alapján érné el.
akkor a public gepre kell telepiteni egy openvpn servert a tavoli kliensek ehhez csatlakoznak, authentikacio jogosultsagkezeles megoldott.
ezutan az openvpn szerver kioszt a sajat virtualis interface-erol egy ip cimet, ami halozatot o osszebridge-el a sajat belso halotokkal es onnantol kezdve a kivulrol bevpn-ezo userek ugyanugy latjak a benti halozatotokat, mintha a natotok mogott lenne.
persze ez csak abban az esetben jarhato ut, ha a natolt halot lehet latni a publikus ip-ju geprol.
Tyrael
A NAT mögötti kliensgépek a mieink, azt telepítünk és futtatunk rajtuk, amit akarunk, és a NAT mögül természetesen kilátnak az Internetre, tehát, a központi szervert is láttyák. Amihez nem férünk hozzá, az a kliensek internet kapcsolatának bármifajta menedzselése. Az lehet bármely kábeles szolgáltató rendszere a végén egy routerrel, vagy lehet akár T-, Pannon, Voda mobil internet.
Hát ha központi webszervert látják, és a központi webszerver is látszik kívülről akkor azon egy VPN szerver indításával megoldódik a kérdés:) A NAT mögötti kliensek tudnak csatlakozni erre a VPN szerverre (mivel az internet felé látnak), és a külsős emberek is csatlakozhatnak erre a VPN szerverre. Még bridgelni se kell, egyszerűen csak engedélyezni, hogy a VPN kliensek "láthassák" egymást.
Ez teljes megoldás szerintem attól függetlenül, hogy csak HTTP-re lenne szükség. Nem tudom pontosan mi a célotok, ezek a belső kliensek mit csinálnak? Web servicet nyújtatának a központi webszervernek?
Szerkesztés:
Picit félreértelmeztem a külső emberek weben authentikálnának, és így érnének el egyes belső oldalakat. Ebben az esetben reverse proxy tényleg, és ha a központi webszerver pedig mondjuk VPNen lenne összekötettésben a kliensekkel.
Most vagy nekem van meg nagyon koran, vagy nektek egy VPN megoldast kellene osszedobni?!
úgy használhatja, mintha a belső hálóján csücsülne és pl. belső ip alapján érné el.
Az tehat egy jo megoldas lenne, peldaul, hogy a
http://kulsogep.inter.net/belsogep/$URL_TOBBI_RESZEcimre azt a weblapot adja (persze autentikacio utan) amit a belso halon a
http://belsogep.lan/$URL_TOBBI_RESZEcim alatt la'tna'? Vagy hogy?
A.
"Adott egy központi, pulic elérhetőségű linuxos webszerver adatbázissal.",
így szerintem a VPN felejtős.
De azért tisztázzuk.
Van 1db publikus szerveretek (1db publikus IP-vel) amelyet HTTP-vel lehet elérni és 'adatokat szolgáltat'.
Bárki, akinek user/pass-sza van, elérheti az adatbázist.
Az 'adatbázis' valójában több adatbázis, amely több fizikai számítgépen helyezkedik el egy belső NAT-olt hálózatban.
Követelmény, hogy ez az adatbázos bárhonnan, bármilyen böngészőt biztosító hálózatból elérhető legyen?
Ha igen, titkosított kapcsolat kell (https) vagy elég a titkosítatlan is (http)?
Ha nem, akkor elvileg VPN-nel megoldható a probléma aránylag egyszerűen.
Ellenben. Előfordulhat-e, hogy egy bejelentkezett személy több adatbázishoz akarjon hozzáférni, amely a NAT-olt hálózatban különböző hostokon található?
Csak HTTP(s), vagy más protokollal is el kell érni a belső hostokat?
"és a NAT routerhez nem férünk hozzá".
OK. De hol van a központi szerver? A router publikus felén egy másik IP-n figyel? Vagy a NAT belső felén és egy forward (port 80) azért megy felé?
A publikus szerveren mi fut, mennyire lehet 'hozzányúlni'?
Ez lenne a konfig?
Publikus Host valahol a Net-en
:
:
Internet
:
NAT
|
+---+---+-------+
| | | |
IH1 IH2 IH3 ... IHn
IH=Inner Host
Sőt, ez a konfig:
Publikus (IP és domén) Host valahol a Net-en (BIX)
:
:
Internet .. .. .. .. .. .. .. .. .. .. .. .. .. ..
: : :
NAT1 NAT2 NATn
| | stb.
+---+---+-------+ +---+---+
| | | | | | |
IH1 IH2 IH3 ... IHn IHx IHy IHz
IH=Inner Host
A NAT mögötti kliens host-ok Video stream-et rögzítenek és nyomnak ip alapon.
Ezt kell "látni" és konfigolni bárhonnan bármilyen gépről böngészővel, vagy kliensprogrammal, de ez már egy következő történet.
(Szétesett a rajzikám, mert a space-eket kigyilkolta a gonosz szerver, de azért remélem érthető.)
code blokk-kal jobb lesz.
Minden NAT-nak külön IP-je van?
Hmmm, hmmmm...
Video stream miatt a VPN nem éppen a legjobb megoldás lesz, mivel az adatot felesleges és erőforrás igényes kódolni.
Elég ide egy(több) tunnel is.
GRE esetleg? (ide lőjetek!)
proxy es auth ldap-bol?
--
“A well placed underscore makes the difference between a s_exchange and a sex_change”
— 8048 Users Manual, Intel 1977.
Konyhanyelven VPN:
Van egy szerveretek, azon fut egy szolgáltatás (alias VPN szerver). A kliensek erre a szolgáltatásra a telepített szoftver segítségével bejelentkeznek, ami pedig egy virtuális hálókábelt (azaz tunnelt) húz a szerverhez. Ergó a NATba és az egész Internetbe bele van húzva egy csatorna, amin azt beszélgetsz amit akarsz.
Ily módon előállt egy virtuális helyi hálózat (VPN azaz Virtual Private Network), amin keresztül úgy tudtok tenni, mintha ott ülnétek egymás mellett.
Ha esetleg szeretnétek olyan szabályozást, hogy ki kit érhet el, az is megoldható némi IPtables mágiával.
Erre gondoltál?
Erre gondoltam.
Feltéve, hogy ezt a vpn drótot minden szolgáltató "át engedi húzni" a szolgáltatásán.
Magyarul hogy egy ilyen vpn működik-e pl. egy mezei edge, vagy umts mobilnetre akasztva is.
VideoStream-et akartok EDGE-en átzavarni?
Ráadásul gondolom nem 1 user/1 server felállásban.
Jól végig gondoltátok?
Nem csak a sávszélesség, hanem a változó késleltetés miatt is.
(Kékszalag?)
Nem kékszalag, azt tavaly csináltuk :) (de nem gsm alapú mobilnettel, mert az egyébként is alkalmatlan brodcast célokra, de az ilyen nyüzsi programok esetén meg még egy google főoldalra is fél percet lehet várni.)
Edge esetén nem kell nagy felbontás, se 30 fps természetesen.
Na akkor még 1x
Ez lenne az igény:
Kliens1 Kliens2 Kliens3 Kliens3 ... KliensN
: : : : :
..................Internet............
:
:
Publikus (IP és domén) Host valahol a Net-en (BIX)
:
:
.............Internet........
: : :
NAT1 NAT2 NATn
| | |
+---+---+-------+ +---+---+ stb.
| | | | | | |
IH1 IH2 IH3 ... IHn IHx IHy IHz
IH=Inner Host
A net ábrázolás kicsit béna, de a hierarchiát szemlélteti.
Kliens meglépi a PH-ot és ott authentikál.
Az auth eredményeként kiderül, hogy melyik IH-ra kapcsolódik (még nem lett megadva, hogy egy auth-tal csak egy host kapcsolat lehetséges-e).
IH felől valamilyen adat elindul PH-n keresztül.
PH fix IP-vel rendelkezik, NATx nem biztos.
IH-knak egy tunnelt kell kiépíteniük PH irányába. Két fő követelmény van ezzel kapcsolatban.
Egyrész a tunnel eröforrás igénye (sávszél, késleltetés, processzor) minimális legyen,
másrészt a kapcsolat 'menedtselt' legyen, azaz szakadás után azonnal kezdje meg az újrakapcsolódást.
Jól látszik, hogy NATx elég gyenge pont a rendszerben.
Az is jól látszik, hogy az *összes* stream mindenképpen átfolyik PH-n keresztül, így az elég nagy terhelésnek lesz kitéve.
Ráadásul, ha pl. két kliens egyidöben ugyan arra a IH-a kapcsolódik, akkor a NATx mögül 2 'egyforma' stream fog elindulni az amúgy is szük sávszélességen PH felé.
Streamingben nem vagyok járatos, de miért nem csak PH kapcsolódik az IH-k hoz, és az lenne a publikus streaming szerver?
Az utolsó bekezdésig mindent 100%-ban megerősítek.
Kérdés, hogy feltétlenül kell-e, hogy az összes stream átfolyjon a PH-n?
Analógia: egy nagy alhálózaton, akár külön-külön NAT mögött csücsülő skype ügyfél a náluk telepített kliensprogram segítségével a központi skype server közreműködésével megtalálják egymást. HA MÁR kiépült közöttük a hang-kép stream kapcsolat, akkor is kontaktban maradnak, ha mondjuk a nagy hálózataik leszakadnak a skype serverről , pl elmegy a külföldi net, stb. Ez személyes tapasztalatom. Hogy hogy csinálják skype-ék, azt persze nem tudom.
Azt is meg lehet csinálni, hogy minden IH csak egy streamet küld, és a PH-nak keresztelt server pedig kiszolgálja azokat, akik ezt akarják nézni. Azt hiszem ezt multicast-nak híjják.
A felhasználandó architektúrát erősen befolyásolja, hogy mit szeretnél csinálni.
Ha a kliensek száma jóval több, mint a források (NAT-ok) száma, akkor mindenképpen érdemes kiépíteni a tartalom elosztó infrastruktúrát nagy sávszélességgel. A forrás streamek csak egy példányban utaznak a szerver(ek)ig, onnan már könnyen szét lehet őket osztani + lehet cachelni, archíválni.
Ha nem ez a hagyományos kevés forrás - sok kliens a felállás, hanem sok forrás - sok kliens, és 1 forráshoz általában 1 (vagy nagyon kevés) kliens kapcsolódik (pl. videófelügyeleti rendszert csinálsz, ahol a lakástulaj be tud lépni, és meg tudja nézni mi a helyzet otthon), akkor meg lehet fontolni az általad leírt elosztott architektúrát.
Szerintem túl kevés az információ a feladatról ahhoz, hogy jó megoldási javaslatot lehessen adni.
Üdvözlettel,
Gergely
Ez az az eset, amikor 2 széplány közül nehezére esik ez ember fiának a választás, hisz mindegyik máshol hordja az előnyeit és hátrányait. :)
Csak amíg emezek nem tolerálják igazán jól, ha megpróbáljuk mindkettő előnyit élvezni, addig a szoftverek erre egyenlőre kevésbé kényesek.
Magyarul már régóta kacsingattam erre is arra is, amikor a működési modellt próbáltam nagy vonalakban elképzelni, és hosszabb távon valószínűleg megvalósítható hibrid megoldás is, mely valahogy ugy nézne ki, hogy a kliens szerverekben választható opció, hogy küldjenek a központi szervernek olyan streamet, amit az tud multicast-olni, vagy ne küldjenek. Persze lehet, hogy ehhez nem egy távmunkás fejlesztő kell már, hanem kibérelhetek egy irodaházat, és beültethetek 20-at. :)
Komolyabbra fordítva, első körben az általad másodikként leírt struktúrát kellene megcélozni.
skype pear to pear halozattot alakit ki ;)
Válasz:
Te zártad ki ezt a lehetőséget azzal; "hogy a központi webszerverre bármilyen platformon, bárhonnan böngészővel bejelentkező userek, ..."
Ugye a Skype meg minden klienshez programot telepít(tet).
Bar szerintem nem kizart. Foleg ha java alapokra epul a progi amit a bongeszo automatice letolt. majd szepen beepul ;)
Tadam es van egy hasonlo technikaja mint a skype.
De biztos van itt olyan aki jobban ert a JAVA-hoz ;)
Ez nagyon szépen hangzik, kérdés, hogy mennyire egyszerű megvalósítani.
Szerintem hasonlo elven fel tudod epiteni mint a skype.
Kell egy server amin adatok halmaza lakozik mind a kliens mint a stream serverek oda csatlakoznak. Majd amikor a kliens kivalasztotta a neki megfelelo dolgot akkor kialakithat rogton egy pear-to-pear kapcsolatot a stream-server es a kliens kozott ;).....
Egyvalamit nagyon elfelejtetek.
A skype egy p2p rendszer -döntöen- adatpáronként egyedi adatfolyammal.
Ez meg egy multicast adatfolyam.
Ne vesszetek már el a programozás szépségeiben!
Elméletben 1 peer-hez csatlakozhat több több peer is, vagyis tudhat multicast-olni a kliens szerver is (OK, nem több 100-at, legfeljebb 2-3-at, és nem gprs/edge kapcsolaton).
De ha ez nagyon bonyi, akkor mehet minden a központi szerveren keresztül is, annak is van előnye. Az üveg sokat kibír, ha pedig nem bírja a cpu, akkor lehet növelni a szerverek számát a központban.
Szerintem ez a legjobb megoldás.
Most már csak matekozni kell, hogy mennyi is az annyi, amit ki kell szolgálni a nagyvilág felé.
Minden szolgáltató engedi, bár lehet hogy QoS-nek lesztek alávetve (ezt mondjuk kétlem, hogy értelmesen meg tudják csinálni). A legnagyobb gyengepont a rendszerben az, hogy ha ezt nyilvánossá akarjátok tenni, a VPN valszeg nem játszik. :) Ha videót akartok streamelni, akkor meg sávszélességileg is vicces lesz.
A VPNnel az egyik legnagyobb baj az, hogy telepíteni, beállítani kell, ami nem triviális pl Windows alatt. Erről valszeg a leendő kivitelezővel valami hosszú és mély szakmai beszélgetést kellene folytatni.
Ha adott esetben nem találtok embert rá, szóljatok. Nem vagyok Linux/hálózat specialista, de csináltam már hasonló vicces dolgokat plusz lehet tudok valakit ajánlani is.
Ebbe a felállásban nem kell vpn-t telepíteni, ha megnézed.
A vpn csak a központi szerver és a linuxos kliensek között kellhet, ha kell, és mindkettőt mi tartjuk kézben.
A userek gépein, amivel a központi szerverrel kommunikálnak már lehet windows.
1 dolog tuti, ez inkabb uzemeltetesi, mint programozasi kerdes.
Tyrael
Akkor ezek szerint célszerű pontosítani, hogy ez nem annyira programozási feladat, mint konfiguráció, webfejlesztés (a központi szerver php/mysql megírása), majd üzemeltetés.
Nem tudom, mennyi PHP / MySQL van a dologban, de ha a VPNes megoldásnál maradtok, akkor a PHP-nek kellene iptablest simogatni. Nem tudom, mit fejlesztetek, de ezen a ponton kezd izgalmas lenni az is, mert nem hiszem, hogy a VPN lenne a tuti megoldás.
Nekem 8 (nyóc), hogy vpn-nek híjják, vagy másnak, csak csinálja meg azt, amit kérek tőle.
No azt hiszem elég szépen kitárgyaltuk, jobban, is, mint egy ilyen fórumon kell, viszont messze nem olyan részletesen, ami alapján valaki ajánlkozhatna a munkára.
Tehát akit esetleg érdekel a dolog, az küldjön egy mailt a
bestefan(kukac)gmailpontkom címre, vagy a HUP-os kontakton keresztül.