tcp tunnel https-en

Segédprogramok

Olyan megoldast keresek, h a kliens oldalon 1 bongeszo van, a masik oldalon meg 1 szerver.
A szerver oldalt menedzselem en.

A kliens oldalon inditok egy tcp kapcsolatot es a tuloldalon egy szerverre szeretnek csatlakozni (mysql).
Lenyegeben egy tunnel https-ben keresztul.

Vmi olyasmit tudok elkepzelni, h van egy extension, amivel ez megoldhato. Letezik ilyen?
Tudom, hogy vannak egesz programok, amikkel lehet https tunnelt csinalni, de en nem olyat akarok.

  • 6811 megtekintés

( STP | 2016. 02. 11., cs – 00:55 )

Websocket lehet a barátod.
Igaz nem böngészőben futó mysql kliens, de mondjuk ilyenről nem is hallottam. ;)

( _Franko_ v | 2016. 02. 11., cs – 10:51 )

A kettő között van egy proxy? Vagy miért lényeges a https? Miért számít itt a böngésző, mi a szerepe?

Annyira enduserrol van szo, h customer es sosem talalkozom vele, nemhogy nem ferek a gepehez.
Mindezzel egyutt nem is mysql-t akar adminolni, hanem az alkalmazas, amivel kapcsolodik, az beszel kozvetlenul a db szerverhez. Nem tud egy webservice-cel kommunikalni, de nem tud elotte inditani a user egy tunnelt kezzel stb.

es az alkalmazast te fejleszted? mert akkor bele kell forditani openssl libet es kozvetlen csatlakozni a szerverre vele akar https-en.

a maisk amit szerintem keresel, az a bongeszobe futo vpn kliens, nem tudom igazna hogy mukodik, de van egy ugyfelunk ahol lattam ilyet, csak ott a kulfodi anyavallalat rendszerehez kapcsolodnak vele, nem tudom ott milyen infrastruktura van ehhez, de explorerben nyit meg egy linket es eloszor ssl vpn bejelentkezest ker aztan megy az rdp kliens az ottani terminal szerverre. telepiteniuk tudtommal semmit se kellett a gepre.

Mert annyi megbízhatatlan és kényes komponensen át megy a kapcsolat, hogy csak a szívás lesz vele, állandóan misztikus hibákat kell majd keresni, de Te tudod.

Ilyen volt, amikor volt egy Apache Httpd, egy szerver oldali tűzfal, a nagy internet felhő, a kliens tűzfala, a kliens böngészője, benne egy Java applet, ami időnként hibát hajigált. Aztán kiderült, hogy az Apache Httpd szerint a KeepAliveTimeout 12 másodperc volt, a szerver oldali tűzfal szerint viszont 10 másodperc. Az Apache Httpd és a Java applet megbeszélte egymással, hogy 12 másodpercig tartják fenn a kapcsolatot, a szerver oldali tűzfal 10 másodperc után bontotta a TCP kapcsolatot, amit a kliens oldali tűzfal nem vett komolyan és nem zárta le a saját TCP kapcsolatát a böngészővel. Az eredmény az volt, hogy ha az utolsó HTTP kérés-választól számítva 10 és 12 másodperc között történt a következő kérés, akkor 120 másodpercig csönd volt, majd az applet dobott egy timeout hibát és lehetett újra próbálni.

Emlékeim szerint hónapokig tartott, amíg sikerült kideríteni, hogy 10 és 12 másodperc között van a hiba és utána két héten át nyomoztunk, hogy melyik komponens és miért csinálja. Na, ilyeneket fogsz a nyakadba venni.

"Nem allitom, hogy egyszeru, de csak standard komponensek vannak benne."

A nagy különbség az, hogy a HTTP egy stateless protokoll, az adatbázis kapcsolatod (illetve kapcsolataid, ha van connection pool) pedig stateful protokoll... elég nagy különbség azokra az esetekre tekintettel, amelyek előfordulnak.

Tehát egy extension-t tud telepíteni a user (rendszergazdája), egy programot pedig nem.
Valamint egy böngészőben el tudja indítani a tunnel-t a user, de egy programot elindítani már nem tud. Már persze a mysql-t használó kliensprogin keresztül, mert annál is ugyanúgy egy ikonra rákattintani. Illetve még a browser is kivétel, azt is el tudja indítani.

Hát nemtom, számomra ez nem tűnik reálisnak.

Én ugyan nem, ez nem az én problémám szóval teljesen nyugodt vagyok :)

Csak azt nem értem, hogy miért ragaszkodsz ehhez a böngészős koncepcióhoz.

Amúgy azt se tartom kizártnak, hogy egy böngésző "magában" nem tud localhost-on portot nyitni. Ez valójában teljesen logikus is lenne, ugyanis nem arra van kitalálva. Persze mindenféle java/activex/whatever hakkolással meg lehet ezt kerülni, láttam én már böngészős java-s VPN megoldást.

Illetve nem csak láttam, szívtam is vele. 64 bites windows-on 64 bites java-val nem ment, vagy épp egy java- vagy böngészőfrissítés után hirtelen nem működött. Olyan is volt, hogy a hivatalosan támogatott böngészővel se ment, a másikkal se, ami ugyan hivatalosan nem támogatott, de általában működött. Majd pár óra után sz*pás után kínomban egy harmadikkal is megpróbáltam, és azzal ment pöccre. Pedig azt állították, hogy azzal biztosan nem működik.

Szóval én nem vállalnék be ilyet ha van más megoldás is. Márpedig van.

( xclusiv v | 2016. 02. 11., cs – 13:00 )

Én stunnel-t használnék kliens és server oldalon is, az pont erre van kitalálva. A böngésző pedig pont nem.

( Zsugabubus | 2016. 02. 11., cs – 16:14 )

Vannak olyan VPN-es tűzfalak, aminek a kliens oldala egy böngészőből indított Java app. De utáltam az ilyet (admin joggal kell böngészned ehhez).

( golgota | 2016. 02. 11., cs – 16:22 )

ssh tunnel oszt kesz

ha linux, akkor egyszeru.
ha win, akkor putty felrak, kapcsolat es tunnel beallit, az alkalmazas meg majd a tunnelezett lokalis protra konnektal...ennyi

Nem, te nem a problemat akarod megoldani, hanem egy problemat szeretnel megoldani a te elkepzelesed szerint. A problemat a leggyorsabban egy suma tunnel oldana meg. Ami ehhez kell azt meg egyszeruen felraknam es kesz.

Az megint mas, hogy most elmondtad, hogy nincs rajta ssh es kesz. Igy nem lehet ezen a modon megoldani. Igy mar ertheto. Nyugodja meg, ujje le, aztan dontsd el hogy a problemat akarod e megoldani, vagy az elkepzelesed megvalositani. A ketto nem ugyanaz.

No, akkor mi a feladat? Van egy app, ami szűrt hozzáféréssel rendelkező (nagyvilág felé 443-as tcp-port van nyitva, nehezítésként authentikációt igényló proxy-n keresztül) gépről kéne, hogy elérje az adatbázist valahol a világ túlfelén?
Ha így áll a dolog, akkor azért valami a tervezésnél erősen félrement... Szerintem :-P

Tokmind1, h felrement a tervezes vagy nem, az is, hogy kinek a hibaja.
Szerintem az is, hogy van-e proxy.

Leirom meg1x, mit szeretnek, csak mashogy.

Semtatikus abra a halozatrol:

tcp service:3306 [privat] --- [privat] gw [publikus] ---- INTERNET --- akarkiakarhol (pl. ugyfel) egy alkalmazassal [privat v. publikus, teljesen mind1]

Szamomra az idealis eset az lenne, ha az ugyfel bongeszovel tudna nyitni egy tcp portnyi alagutat https-en keresztul a tcp service-hez.
Valojaban (perpillanat) teljesen mind1, h mysql vagy barmi mas van ott.

A kerdes az, hogy lehetseges-e ez technikailag es ha igen, van-e mar ra kesz megoldas.

NEM akarok ssh tunnelt csinalni, NEM akarok mysql-t adminolni phpmyadminnal. Aki ezeket eroltetni, az menjen az mysql adminolas ssh tunnelen keresztul topic-ba.

Egyelore ugy tunik, hogy az sem lehet elegseges megoldas alternativakent, hogy megcsinalom bongeszon kivul random httptunnel megoldassal, mert a bongeszonek SAML authentikalnia kellene a tunnel letrehozasa elott es az nem fog menni feltetelezem.

És gondolom a publikus interneten titkosított forgalmat szeretnél, 443-as porton átzavarva. A te oldaladon ehhez mindenképp kell valami, ami az ssl-t végződteti (stunnel), és betolja a tcp-kapcsolatot a DB-re. Viszont mivel 443-as port, így fel kell arra készülni, hogy HTTP-kérések esnek be a DB-re, ami fene tudja, mivel jár...
A másik végén is kell valami, a becsomagol/portot forgat dologhoz - ez az, amit a tetszőleges böngésző önmagában nem fog megtenni neked.

Elég régi alapelv egyébként, hogy DB-t direktben nem lógatunk ki a publikus netre, ez alapján az alkalmazásod rossz helyen fut: nem véletlenül vannak a webszerver - appszerver - DB felállásban megvalósított szolgáltatsok - ezzel ugyanis csak kontrollált hozzáférés van a DB-hez. Persze ha Java-ban nem rakható össze az alkalmazás, akkor marad a gányolás, annak minden hátrányával és sz0pásfaktorával együtt.

> a publikus interneten titkosított forgalmat szeretnél

Termeszetesen, alapvetes.

> 443-as porton átzavarva

Nem. HTTPS-en atzavarva.
Ha csak siman barmi tcp porton akarnam, akkor megoldana egy szimpla portforward es vhogy titkositva (pl. stunnel...vagy barmi).

> tetszőleges böngésző önmagában nem fog megtenni

Ezert irtam, h vmi extensionnel. Ill. egyebkent ugy tippelem, hogy java applettel is megoldhato lenne...de azzal manapsag mar nem lennek elobbre.
Belegondolva akar javascripttel is mukodhetne elmeletileg es akkor extension sem kellene.

Azaz van/lehet közben egy eszköz, ami a 443-as porton futó forgalmat ki/átcsomagolja? Mert azzal orrrbitálisat fogsz szívni... Ha csak egy sima webes proxy, akkor az nem bántja, és lehet bármi az ssl-es csőben, bár ahogy már szó volt róla, a http/https jellegénél fogva más protokoll, mint egy DB-kapcsolat. Ha meg sokáig fenntartod a csatornát, az a proxy/hálózat üzemeltetőjének fog feltűnni, hogy néddeno, ez a kliens egy session-ben mennyi adatot tolt/húzott át.

JavaScript-ben megírva...? Hmmm... Sok szerencsét, én már csak a popcorn&soda párost fogom kérni :-P A Java applet talán - hiszen az esetleg tudhat localhost:12345-re bindolni, és valahogy http get/post kérésekkel a komplett kéréseket áttolni a túloldalra, ahol a "párja" fogadja, és forgatja be a DB felé, és a tcp-session-t életben tartva a DB válaszát visszaküldi - természetesen (hogy ne legyen feltűnő) épkézláb/szabályos HTTP-válaszban. Ugyanis azzal, hogy https-en szeretnéd átzavarni, azt mondod, hogy SSL/TLS-be csomagolt szabványos HTTP-forgalmat kell csinálni a DB és az app közötti forgalomból.

Mondjuk úgy, hogy nem lesz egyszerű...

> Azaz van/lehet közben egy eszköz, ami a 443-as porton futó forgalmat ki/átcsomagolja? Mert azzal orrrbitálisat fogsz szívni... Ha csak egy sima webes proxy, akkor az nem bántja, és lehet bármi az ssl-es csőben, bár ahogy már szó volt róla, a http/https jellegénél fogva más protokoll, mint egy DB-kapcsolat. Ha meg sokáig fenntartod a csatornát, az a proxy/hálózat üzemeltetőjének fog feltűnni, hogy néddeno, ez a kliens egy session-ben mennyi adatot tolt/húzott át.

Nem erdekel, mennyi adatot huz at. Azon keves alkalmakkor, amikor ehhez nyulna a user, eppenseggel az lenne a lenyege, hogy adatot toljon at pl., meg lefuttasson nehany sql parancsot vegso soron.

> Mondjuk úgy, hogy nem lesz egyszerű...

Ugy sejtem, 99% most mar, h nem lesz kesz megoldas. Mivel ez egy alternativa csupan, nem a kizarolagos lehetoseg, valoszinuleg nem ebbe az iranyba fogjuk megoldani. De en a masikat szerettem volna elkerulni.
Explicit ezt a feature-t meg nem fogjuk lefejleszteni csak ezert.

Azert nem irtam reszletesen a problemarol, mert senki sem kerdezett rola (ertelmeset).
Konkretan amire te valaszoltal (golgota) leszukitette ill. pontosabban atminositette a temat arra, hogy barmi modon el kell erni egy mysql szervert.
Pedig rohadtul nem errol van szo.

Irjak autos hasonlatot?:)

Ellentmondasba keveredtel: "barmi modon el kell erni egy mysql szervert" vs. "az en elkepzelesem szerint kellene elerni egy szervert"
Ahol is egy 443-as portra szeretnek konnektalni, de az nyitva sincs a tavoli hoszton (a 3306-van nyitva). Engedd meg hogy en is rajzoljak:

ugyfel alkalmazasa->tcp conn to remotehost:443 -----> opened remotehost:3306

Na mar most akkor legalabb a remote-on kellene lennie valaminek ami atiranyitja a 443-asra erkezo forgalmat a 3306-ra. Ha semmi mas nem megy a 443-on, akkor erre akar egy netcat is jo lenne. De te valoszinuleg titkositanad is a forgalmat, azaz a netcat nem eleg. Ha nem clear textben akarod utaztatni a neten a mysql lekerdezeseket, akkor bizony az a csatolnat tenyleg TLS-be kell csomagolni.

Azaz a tavoli gepen kell lennie egy programnak, ami a 443-on fut es ismeri a cert-et amivel titkositod a forgalmat, majd kicsomagolja a forgalmat es eliranyitja a 3306-ra, utana fogja es a valaszt becsomagolja es visszakuldi a kerest az inditohoz (a kliensprogramhoz).

Zeller egyebbkent mar elmagyarazta. :D

Hat ott a C, a Java, vagy a C#. Ezekkel tuti meg lehet irni egy SSL based mysql proxyt.

En gyorsan megcsinalnam tunnellel es igy az ugyfel gepen csak siman "localhost:tunnelport" connectionstringet hasznalnek. Ha "barmi modon el kell erni" :D

( haga | 2016. 02. 11., cs – 17:02 )

Lehet nem ilyenre gondolsz, de nézd meg az openvpn als-t.

( connor v | 2016. 02. 12., p – 12:56 )

[szerk: nem jó megoldás]

Én nem direktbe' matatnám a mysql-t.

De:)

A hattere a dolognak az, hogy van egy webes alkalmazas, ami egy desktop alkalmazas webes reinkarnacioja. Viszont a webes meg nem ismer annyit, mint a desktop, vannak funkciok, amiket csak azzal lehet megcsinalni. Idovel (kozel) minden funkcio at fog kerulni, de amig nem, a desktop alkalmazasnak is kell hozzaferes. Jellemzoen egyebkent admin funkciokrol van szo, igy nem jellemzo, hogy allandoan hasznalni kellene.

Ket lehetoseg adott. Vmi remote desktop megoldas, ami nem tetszik a jellegenel fogva. A masik, hogy vogy megoldjuk a a fentit.
A user gepehez nem ferunk hozza es nem akarok ra semmit telepiteni a szuksegesnel tobbet (pl. openvpn-t nem).

Viszont mivel a desktop kliens lenyegeben deprecated, nemnagyon szeretnenk fejleszteseket eszkozolni rajta.

Az utolsó mondat a kulcs. :)
Emiatt a remote desktop egészen jó ötlet is lehet, függően attól, hogy milyen mennyiségben használnák (mivel admin funkciókról van szó, gondolom kevesen).

Ha én lennék, az admin funkciók bonyolultságától függően megcsinálnám úgy, hogy a kívánt funkció elérhető legyen REST felől amíg a webes UI nem készül el.
Már csak azért is, mert ha jó az API, akkor arra a böngészőben futó web app is rá tud ülni később.
A desktop appot meg átírnám, hogy az admin funkciókat restből intézze ezentúl. Az elmondottak alapján nekem ez még egy szimpatikus út lenne (még ha neked nem is).

( Zs | 2016. 02. 12., p – 21:12 )

Veszel egy NatASQ tűzfalat, bekonfigurálod, hogy a portál oldala a neked tetsző módon, de https alapokon elérhető legyen. Utána a NetASQ saját fura nevű VPN-jét bekonfigurálod, ami lényegében arról szól, hogy a kliens mely portján keresztül éred el a NetASQ tűzfal mögött adott IP adott portját.
Kliens böngészőből belép a portál oldalra, azonosítja magát, majd rányom a VPN gombra. Letöltődik a Java Applet, lebindel a 127.0.0.1:$KONFIGBANMEGADOTTPORT-ra. Innen kezdve a Java Applet és a NetASQ között https forgalom gurul, a forgalom meg úgy néz ki, hogy:
kliensvacka<->JavaApplet a helyi porton : JavaApplet a NetASQ felé https alapokon az ott megadott porton <--> NetASQ terminálja a kapcsolatot és tovább löki a konfigban megadott IP:port felé <--> szervered bármilyen protokollal.