tunnel https felett, Windows és Linux között - mivel?

Hálózatok egyéb

Van egy nagyon szigorú tűzfal, gyakorlatilag csak http/https megy ki rajta.

Bentről a windows-os géppel különféle kliensek szeretnének ide-oda kapcsolódni. Pl. a céges VPN-hez valahova, a céges levelezőrendszerhez valahova. Meg szeretnék ssh-val belépni két gépre.

Van kint két Linuxos gép, ami használható lenne a tunnel másik végének. Az egyiken a https port sem használt, csak a http, a másikon http/https-en figyel a webszerver.

OpenVPN-t próbáltam az üres https porton, TCP-n, ez korábban más ügyfelektől működött. Itt nem.

Szóval most valami más megoldást keresek.
-Jó lenne, ha a webszerveren keresztül menne, mert az a gép, amelyik http és https portja is foglalt, lényegesen jobb netkapcsolattal bír, mint a másik (ami egy ADSL-en lóg, szóval felfelé irányban (ami nekem lefelé) nagyon lassú). Szóval az ideális megoldás valami olyan, ami a szerver oldalon egy cgi-vel vagy ilyesmivel beszélget.

-De minimum az kellene, hogy legyen egy olyan kapcsolat, amit win alól fel lehet építeni (valami programmal), és van egy olyan csatornám, amin keresztül 1) tudok kifelé kapcsolódni (gw a tunnel másik vége)

Amiket most gyors keresgéléssel találtam, azok linux alá érhetőek el, nem tudom, win alól melyiket lehetne használni, és nem láttam többet annál, hogy egy tcp kapcsolat, stdin-ről stdout-ra.
Szóval még akkor erre is rá kéne illeszteni valamit, hogy pl. a levelezés működjön.

Tehát a kérdésem az, hogy windows-os klienssel használható http tunellel van-e tapasztalata valakinek, melyik termék, stb.

G

  • 2465 megtekintés

Nem tudom, ugyanarra gondolunk-e. Amit én ismerek stunnel néven, az valami olyasmit csinál, hogy a szerveremen vannak a titkosítást nem ismerő régi programok, és az adatfolyamot becsomagolja.

Ha te ugyanerre gondolsz, akkor nem tudom, hogy tudnám vele mondjuk az openVPN vagy az ssh adatfolyamomat https-nek álcázni, és a tűzfalon átküldeni.

URL esetleg?

G

Szia,

url: http://www.stunnel.org/

A HTTPS egy SSL-be ágyazott HTTP, vagyis van egy SSL kapcsolat (tunnel) a 2 oldal között, és ebben mennek - titkosítotlanul - a HTTP request-ek és reponse-ok.

Az stunnel olyat tud, hogy 2 gép között felépít egy SSL tunnel-t, és az megy benne, amit akarsz. Láttam már mysql-t, smtp-t, szóval titkosítatlan szolgáltatásokat az interneten keresztül stunnel-en keresztül áthúzva.
Szóval ha a tűzfal csak azt nézi, hogy valódi SSL forgalom van a 2 oldal között akkor ezzel szerintem átvághatod.

Röviden vázolom, hogy mire gondolok. "A" a helyi kliensed, "B" a távoli server, amire ki akarsz menni.
B-re raksz egy squid-et, ami localhost-on figyel a 3128-as porton.
B-re raksz egy stunnel-t, ami figyel a külvilág felé a 443 porton, és a bejövő forgalmat a localhost:3128-ra irányítja
A-ra raksz stunnel-t, ami B:443 és localhost:9876 közötti forgalmat viszi át
A-n http proxy-nak beállítod a localhost:9876-ot

Így elvileg van egy SSL kapcsolatod ami az is, benne meg az megy, amit akarsz.

Viszont ha jól tudom lehet olyat csinálni (rémlik mintha a zorp pénzes változata is tudná), hogy a https-t proxy-zza, vagyis a te browser-ed és a proxy között felépül egy ssl tunnel, és a proxy és a webserver között is, így azt a forgalmat is tudja ellenőrizni a proxy. Ha ilyen van akkor az stunnel-t nem fogja engedni, mert nem http forgalom van az SSL tunnel-ben.

Hát, ha az OpenVPN-t nem sikerül beüzemelni, akkor lehet, hogy ez lesz.

Mindenesetre az OpenVPN is csak valódi SSL forgalom lenne. Szóval nem látom, hogy ez nekem mitől lenne jobb. Persze ha az OpenVPN mondjuk nem megy, ez meg igen, az egy elég jó érv :-D

Azt nem tudom, hogy a HTTPS kapcsolat hogyan épül fel, de feltételeztem, hogy mielőtt titkosított lesz, az előtt nézi a tűzfal.
Szóval utánanézek este az OpenVPN Connect-nek először.

A https proxyzást értem, de nem nagyon tudom elképzelni. Ha a browserem a proxyval beszél, az olyan, mint egy man in the middle attack. A proxynak biztosan nem lesz meg az eredeti céloldal titkos kulcsa, akkor meg a böngésző figyelmeztet, hogy hohó, eltér a kulcs az URL-től.

Nem?

G

( triv | 2008. 04. 17., cs – 15:27 )

Szerzel egy gepet (akar virtualisgep.hu), aminek a 443-as portjara teszel egy ssh-t..
Virtualis gepen futattsz egy proxyt
Az sshval a virtualis gepen levo proxyra kiepitesz egy tunnelt
A gepen beallitod proxynak a localhost:[ssh tunnel enenk a vegenek a portja] -t.
S ennyi.

[szerk: mondjuk a mail nemtom h tud-e proxyn ekresztul emnni...sebaj, kiepitesz meg tunneleket direktbe a mailszerverre ]

Várj, most fel kell fogjam.

Tehát van egy távoli gépem, mondjuk legyen a neve U. Ezen most fut ugyan egy ssh a 22-es porton, de vagy arra ráveszem, hogy figyeljen a 443-on is, vagy másik sshd, mindegy.

U gépen futtatok egy proxyt. Milyen proxyt? Mondjuk squid?

Az ssh-val a virtuális gépen levő proxyra kiépítek egy tunnelt...

Itt elakadtam. Mi az, hogy az ssh-val kiépítek egy tunnelt? Úgy érted, a helyi gépről nyitok egy ssh kapcsolatot mondjuk puttyal?
Na ezt holnap kipróbálom, de nagyon csodálkoznék, ha menne. Ha az OpenVPN nem ment, mert a tűzfal kiszűrte, akkor miért menne az ssh? Gondolom kizárólag https forgalmat enged (ha már szűrnék a forgalom tartalmára, én nem engednék mást).

Azt hiszem, értem, mit javasolsz. És azt hiszem, hogy ez így nem fog működni. Persze ha menne jó lenne.

Az eredeti kérdésre (vagyis nem ssh tunnel, hanem https tunnel) nincs ötleted?

G

( colos | 2008. 04. 17., cs – 16:48 )

"korábban más ügyfelektől működött. Itt nem."

ezt kifejthetned bovebben, bar gyanitom hogy isa szerver es ntlm authentikacio lesz a hiba

udv Zoli

ISA szerver? NTLM authentikáció?

Szép szavak. Fogalmam sincs, mit takar.

De kifejtem bővebben, tehát:

voltak olyan ügyfelek, ahol az openVPN-t elindítva tcp/https porton simán csatlakozott egymással a kettő. (Ott spec. tudom, hogy squid volt, jelszót kellett adni brózoláskor, de nem emlékszem, hogy az openVPN-nek kellett-e, és ha igen, hogyan jelszót megadnom).

Itt, brózoláshoz nem kell jelszó, és természetesen nincs a gépem az ügyfél domain-jében, és természetesen saját felhasználóval jelentkezek be a saját gépemre, nem az ügyfél domainfelhasználójával. Hálózati erőforrásokhoz (nyomtató, fájlszerver hozzáféréskor) megadom az ügyfél domain-jében érvényes felhasználónevemet, jelszavamat. De mondom, brózoláshoz nem kell megadnom semmi jelszót.

Az openVPN-t elindítva ilyesmit ír:

Thu Apr 17 15:22:43 2008 WARNING: No server certificate verification method has
been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Apr 17 15:22:43 2008 Re-using SSL/TLS context
Thu Apr 17 15:22:43 2008 LZO compression initialized
Thu Apr 17 15:22:43 2008 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Apr 17 15:22:43 2008 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Apr 17 15:22:43 2008 Local Options hash (VER=V4): '69109d17'
Thu Apr 17 15:22:43 2008 Expected Remote Options hash (VER=V4): 'c0103fa8'
Thu Apr 17 15:22:43 2008 Attempting to establish TCP connection with 195.70.xxx.xxx:443
Thu Apr 17 15:22:43 2008 TCP connection established with 195.70.xxx.xxx:443
Thu Apr 17 15:22:43 2008 Socket Buffers: R=[8192->8192] S=[64512->64512]
Thu Apr 17 15:22:43 2008 TCPv4_CLIENT link local: [undef]
Thu Apr 17 15:22:43 2008 TCPv4_CLIENT link remote: 195.70.xxx.xxx:443
Thu Apr 17 15:22:43 2008 Connection reset, restarting [0]
Thu Apr 17 15:22:43 2008 TCP/UDP: Closing socket
Thu Apr 17 15:22:43 2008 SIGUSR1[soft,connection-reset] received, process restarting
Thu Apr 17 15:22:43 2008 Restart pause, 5 second(s)

Aztán ez ismétlődik. Otthonról megy simán ugyanezzel a géppel, ugyanezzel a konfiggal a kapcsolódás.

mi a kérdés? :-)

Van az ügyfél. Van az ügyfélnek egy windows domain-je, az ebbe tartozó gépeket az én gépemről (ami az én cégem domain-jébe tartozik) úgy tudom elérni, hogy kapcsolódáskor feldob egy ablakot, ahová meg kell adnom egy ügyféldomain\user és jelszó kombinációt.

Ez kell az exchange-hez kapcsolódáshoz, meg a dokumentációkat tároló fájlszerverhez, meg a nyomtatóhoz. Máshoz nem.

Mivel máshoz (pl. böngészés) ez nem kell, ezért nem tudom hol releváns.

De ez persze nem jelenti azt, hogy biztos nem releváns, nem windows rendszergazda vagyok... szerencsére :-)

G

Lehet, hogy buta kérdés, de miért kell nekem azzal foglalkoznom, hogy hogyan épül fel a rendszer?

Én azt szeretném, hogy ahogyan a browser lekér egy https weblapot, úgy kommunikáljon egy program, és biztosítsa nekem a tunnelt.

Megnéztem, a Firefox azt mondja, hogy ő direktben kapcsolódik az internetre. (ami persze valószínűleg transzparens proxyt jelent).

Miért gondoljátok, hogy nekem proxyt kell konfigurálnom, meg authentikációval kell szórakoznom, amikor a böngészőkben ezek nem kerültek elő?

Én simán azt feltételezem, hogy van egy tűzfal, ami protokol elemzést végez, és látja, hogy a https porton baromira nem https forgalom zajlik, és ezért visszadobja a francba.

Ha ismerném a http protokollt, akkor simán telnettel lekérnék egy távoli gépről egy valami oldalt, csak hogy lássam, működik-e proxybeállítás és auth nélkül. (gondolom, működne).
Gyakorlatilag a tunneltől is ugyanezt a működést várnám.

És látom, hogy vannak is ilyen jószágok, pl. van a debian csomaglistában egy httptunnel nevű, meg van egy corkscrew, ezek mind ezt ígérik. Csak nincs windows oldali kliens hozzájuk (pontosabban nem találtam).

Találtam egy Barracuda https tunnel nevűt, csak annak a szerveroldali része fizetős, és zárt. A saját laptopomra hajlandó volnék szemetet tenni, de a távoli gépre nem szeretnék.

Látom, hogy senki se ebbe az irányba indult (kivéve talán a szűkszavú stunnel kommentet, amit nem értek), hanem alternatív megoldásokat ajánl mindenki, illetve az openvpn nem működését próbáljátok elhárítani.

És ez jó, és hálás vagyok, csak félek, hogy zsákutca.

Köszönöm a segítő szándékot mindenesetre.
G

Nem biztos, hogy nincs proxy. Sőt, szerintem van proxy.

Csak éppen transzparens, és ezért nem látszik. De azért ellenőriz, és szűr.

Hogy mást ne mondjak, volt olyan, amikor egy bizonyos oldalt nem engedett, merthogy game kategória.

Szóval valaki valahol elemzi, és engedélyezi a forgalmat.

G

Host nerdlabs.org
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Accept text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language hu,en-gb;q=0.8,en;q=0.5,fr;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
Connection keep-alive
Referer http://hup.hu/node/53853

Ezt írja. Ebből lehet látni valamit?

Igen, rátaláltam napközben, de kipróbálni még nem tudtam.

És elsősorban tapasztalatok érdekeltek volna, hogy mennyire könnyű használni egy ilyen cuccot.

És azon kívül, hogy 2006-os az utolsó frissítés, nem tud https-t. Márpedig olyan gépem nincs a nagyvilágban, amin a http port ne lenne már használatban. :-(

G