Megint stunnel.

A problémám a következő lenne: Linuxos szervert kellene öszzekapcsolni Windowsos kilensel egy nem megbízható hálózaton (internet) keresztül. Mivel a probléma csak egyetlen egy szolgáltatást érint, úgy gondoltam az stunnel lessz a megoldás. Bekonfiguráltam a klinesen, bekonfiguráltam a szerveren, azonban az eredmény eléggé - háát.... - furcsa. Az MySQL kiszolgálóhoz a kliens program nem tud kapcsolódni, azonban az stunnel szerint a kommunikáció végbe ment (azt hiszem).
Két gondolatom van: az stunnel nem tud fenntartani prezisztens kapcsolatokat, és ezért alkalmatlan a feladatra; vagy rosszul lett valami beállítva és ezért szált el az egész.
Ha valaki konfigurált már stunnelt, illetve vannak stunnel-es tapasztalatai, szívesen vennék egy kis segítséget. (mindjárt mellékelem a konfig fájlokat, logokat, stb...)
Előre is köszönet....

A kliens oldali stunnel log-ja:
[code:1:31e6651e0d]
2005.06.17 13:57:46 LOG5[184:1616]: stunnel 4.10 on x86-pc-mingw32-gnu WIN32+IPv6 with OpenSSL 0.9.7f 22 Mar 2005
2005.06.17 13:57:47 LOG7[184:1720]: RAND_status claims sufficient entropy for the PRNG
2005.06.17 13:57:47 LOG6[184:1720]: PRNG seeded successfully
2005.06.17 13:57:47 LOG5[184:1720]: No limit detected for the number of clients
2005.06.17 13:57:47 LOG7[184:1720]: FD 196 in non-blocking mode
2005.06.17 13:57:47 LOG7[184:1720]: SO_REUSEADDR option set on accept socket
2005.06.17 13:57:47 LOG7[184:1720]: mysqls bound to 0.0.0.0:3306
2005.06.17 13:57:53 LOG7[184:1720]: mysqls accepted FD=224 from 127.0.0.1:1155
2005.06.17 13:57:53 LOG7[184:1720]: Creating a new thread
2005.06.17 13:57:53 LOG7[184:1720]: New thread created
2005.06.17 13:57:53 LOG7[184:836]: mysqls started
2005.06.17 13:57:53 LOG7[184:836]: FD 224 in non-blocking mode
2005.06.17 13:57:53 LOG5[184:836]: mysqls connected from 127.0.0.1:1155
2005.06.17 13:57:53 LOG7[184:836]: FD 244 in non-blocking mode
2005.06.17 13:57:53 LOG7[184:836]: mysqls connecting 192.168.0.65:3307
2005.06.17 13:57:53 LOG7[184:836]: connect_wait: waiting 10 seconds
2005.06.17 13:57:53 LOG7[184:836]: connect_wait: connected
2005.06.17 13:57:53 LOG7[184:836]: Remote FD=244 initialized
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): before/connect initialization
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 write client hello A
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 read server hello A
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 read server certificate A
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 read server done A
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 write client key exchange A
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 write change cipher spec A
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 write finished A
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 flush data
2005.06.17 13:57:53 LOG7[184:836]: SSL state (connect): SSLv3 read finished A
2005.06.17 13:57:53 LOG7[184:836]: 1 items in the session cache
2005.06.17 13:57:53 LOG7[184:836]: 1 client connects (SSL_connect())
2005.06.17 13:57:53 LOG7[184:836]: 1 client connects that finished
2005.06.17 13:57:53 LOG7[184:836]: 0 client renegotiatations requested
2005.06.17 13:57:53 LOG7[184:836]: 0 server connects (SSL_accept())
2005.06.17 13:57:53 LOG7[184:836]: 0 server connects that finished
2005.06.17 13:57:53 LOG7[184:836]: 0 server renegotiatiations requested
2005.06.17 13:57:53 LOG7[184:836]: 0 session cache hits
2005.06.17 13:57:53 LOG7[184:836]: 0 session cache misses
2005.06.17 13:57:53 LOG7[184:836]: 0 session cache timeouts
2005.06.17 13:57:53 LOG6[184:836]: SSL connected: new session negotiated
2005.06.17 13:57:53 LOG6[184:836]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
2005.06.17 13:57:53 LOG7[184:836]: Socket closed on read
2005.06.17 13:57:53 LOG7[184:836]: SSL write shutdown
2005.06.17 13:57:53 LOG7[184:836]: SSL alert (write): warning: close notify
2005.06.17 13:57:53 LOG7[184:836]: SSL_shutdown retrying
2005.06.17 13:57:53 LOG7[184:836]: SSL doesn't need to read or write
2005.06.17 13:57:53 LOG7[184:836]: SSL alert (read): warning: close notify
2005.06.17 13:57:53 LOG7[184:836]: SSL closed on SSL_read
2005.06.17 13:57:53 LOG7[184:836]: Socket write shutdown
2005.06.17 13:57:53 LOG5[184:836]: Connection closed: 31 bytes sent to SSL, 114 bytes sent to socket
2005.06.17 13:57:53 LOG7[184:836]: mysqls finished (0 left)
[/code:1:31e6651e0d]

és a kliens konfigja:
[code:1:6aa16105b1]
debug = 7
client = YES

[mysqls]
accept = 3306
connect = szerver.wesztanetwork.hu:3307
[/code:1:6aa16105b1]

A szerver konfigja:
[code:1:6ea4b4c757]

client = no

chroot = /var/lib/stunnel/
setuid = stunnel
setgid = nogroup

pid = /var/run/stunnel.pid

CApath = /etc/stunnel/certs

cert = /etc/stunnel/stunnel.pem

[mysqls]
accept=3307
connect=localhost:mysql
[/code:1:6ea4b4c757]

Tehát, ha ezekből van valakinek valami ötlete, hogy mi lehet rossz, kérem ossza meg velem ezt a tudás. Vagy csak ha szimpán már van stunnelben valami tapasztalata és ötlete...
Előre is köszönet a segítségért...

[quote:85ab9dbda6="FoREE"]lehet h nagyon trivialis, de a my.cnf -ben ugye nincs skip-networking ?

A MySQL szerver (amennyiben nem az stunnelen keresztül érem el) tökéltesen működik. Több alkalmazás (adatbázis) is fut rajta, úgyhogy nem hinném, hogy ott a hiba. Biztos vagyok abban, hogy az stunnelnél van valami elszabva.

[quote:57660e5ee8="samson"]zither

-kiszedned a chrootot egy pillanatra?
-CApathot miert allitottad be? client cert authot is akarsz? de a kliensnel nincsen cert beallitva...
kiszedned a CApathot egy pillanatra?

Kiszedegettem őket, de nem oldották meg a problémát...

...aztán végül több napi szenvedés után (ezért nem jelentkeztem ennyi ideig) rájöttem a hibára. A konfiguráció tulajdonkéépen jó, a hiba nem ott volt.

A következő a felállás:
Az stunnel megkavarja a MySQL host hitelesítési metódusát. A MySQL ugyanis a hitelesítéshez felhasználja a kapcsolódni kívánó kliens hálózati adatait is, ez pedig stunnel alakalmazása esetén az alagút kijárata lessz. Vagyis csak akkor hitelesít a MySQL stunnel alagutazás esetén ha:
1.- A kijárat a 127.0.0.1 IP című visszahurkolóra kerül, ha localhost névvel hivatkozunk ugyanerre, az nem jó (még roszabb megoldás, ha a kijáratnak a saját gépnevet adjuk meg)
2.- Az @localhost felhasználó megfelelő jogokkal rendelkezik ahhoz az adatbázishoz, amihez a tunnelen keresztül kapcsolódni szeretnénk. (ez a felhasználó egy előre beálított felhasználó, akinek semmmihez nincs joga, és a 127.0.0.1-es visszahurkolón jön be).
Ha ez a két feltétel nem teljesül, a kapcsolat nem jön létre, és mivel stunnel specifikus a dolog, jön a látszólag minden jó, de mégse működik effekt.
Hogy miért nem jó, ha a kijárat a localhost (vagyis a kiszolgálói stunnel.conf-ban a "connect=localhost:3306"), azt nem tudom elképzelni sem, mondjuk a sajátnév esetén a forrás és a cél ugyan az lesz, ami valószínűleg biztonsági szempontok miatt ki lehet lőve a MySQL-ből (ez csak egy magán feltételezést, egyáltalán nem biztos, hogy így is van).

Mindenesetre köszönöm mindenkinek a segítséget, mégha most éppen megoldást nem tudtak nyújtani az ötletek... (vagy mégis?)

[quote:fb86031302="boobaa"]FoREE kérdése másképp: ha stunnel nélkül használod a MySQL-t, akkor a helyi háló másik gépeirõl elérhetõ?

Igen. Lásd: Pént Jún 17, 2005 3:00 pm

(Bocsi, hogy ilyen későn reagáltam, de sajnos úgy alakult, hogy most hétvégén nem tudtam nethez férni.)