Verbindung zu MySQL

[Spoocky]

Ich habe eine Anwendung geschrieben, die Verbindung zu einer MySQL-Datenbank aufnimmt. Solange ich intern im lokalen Netz meine Anwendung starte ist alles ok.

Möchte ich nun von außerhalb dieses lokalen Netzes, sprich vom Internet aus, von meiner Anwendung die Verbindung zur MySQL-Datenbank nutzen, kann keine Verbinung hergestellt werden, weil die Firewall des lokalen Netztes den Port für die MySQL-Zugriffe blockiert, was aus sicherheitstechnischen Gründen richtig ist.

Jetzt stellt sich mir die Frage, ob man in einer Anwendung so eine Art 'tunnelling' programmieren kann, sodass ich über HTTP eine Verbindung zur MySQL-Datenbank herstellen kann?

 

[tuxedo]

Du hast die Forumsuche nicht benutzt, oder? Weil genau das Problem hatte ich vor längerer Zeit auch, weshalb ich angefangen hab einen JDBC Treiber zu schreiben der genau das ermöglicht.

Guckst du hier:

http://www.java-forum.org/de/topic33612_mysql-over-php-to-java-bridge.html

und hier:

http://www.java-forum.org/de/topic53345_erste-jpmdbc-alpha-version-fertig.html

und zuguter letzt hier:

http://jpmdbc.dev.java.net

Grüße,
Alex

 

[Dante]

wenn es aus sicherheitsgründen gut ist, den port zu sperren, warum ist ein Tunnel dann die Lösung?

 

[tuxedo]

;-) Das ist was dran.

Auf der anderen Seite: Die meisten Webspaces bieten PhpMyAdmin an. Das ist dann nicht viel sicherer wie JPMDBC.

An HTTPS Support wird jedoch gerade gearbeitet.

 

[AlArenal]

Auf der anderen Seite: Die meisten Webspaces bieten PhpMyAdmin an. Das ist dann nicht viel sicherer wie JPMDBC.

An HTTPS Support wird jedoch gerade gearbeitet.

Und jeder halbwegs gescheite Hoster lässt phpMyAdmin nur über HTTPS laufen. Hier ist auch die Protokollierung von Zugriffen leichter und damit die Identifizierung und Rückverfolgung von evtl. Eindringversuchen.

 

[tuxedo]

Deswegen wird ja auch am HTTPS Support gebastelt ;-)

Zur Protokollierung: Apache loggt doch HTTP genau wie HTTPS? Wo ist da der Unterschied? Sicherer ist HTTPS, keine Frage. Aber was daran besser sein soll bei der Rückverfolgung und Protokollierung musst du mir bitte erklären.

- Alex

 

[Dante]

https ist vorallem noch langsamer. Hast du da schon benchmarks gemacht? das wird doch langsam ohne ende, oder?

 

[tuxedo]

Nein hab ich nicht. Ich wüsste jetzt auf Anhieb auch nicht wie ich's anders sicherer machen soll und die performance auch nicht drunter leidet.

 

[AlArenal]

https ist vorallem noch langsamer. Hast du da schon benchmarks gemacht? das wird doch langsam ohne ende, oder?

Du bist auch ein lustiger Vogel. Im ersten Satz stellst du mal einfach ne Behauptung als Tatsache hin und danach fragst du andere, ob diese Benchmarks gemacht haben, um deine Behauptung zu stützen.

 

[Dante]

ja, wenn man schon mal etwas mit ssl und http zu tun hatte dann weiss man, dass da ne menge mehr last erzeugt wird (vorallem dioe handshakes müssen ordentlich gemacht werden, da diese ewig viel overhead erzeugen). Dass jeder application server echte sql-verbindungen schon poolt um keinen overhead mit dem aufmachen neuer verbindungen erzeugen sollte wohl auch bekannt sein. Ob das tunneln über ein weiteres protokoll inkl. serialisierung dann wirklich komplett ohne geschwindigkeitsnachteil abgeht, halte ich für deutlich unwarscheinlicher als das gegenteil.

Insofern gebe ich dir den lustigen vogel gerne zurück. Wenn ich jemand wirkluch hinsetzt um das zu schreiben wird man sich doch wohl mal erkundigen dürfen, ob er bedacht hat, dass das deutlich langsamer werden könnte.

Da du dich in diesem Thread auch nich wirklich mit Ruhm beckleckert hast, solltest du vielleicht etwas kürzer treten. Wir sind doch alle erwachsen, oder?

@Alex: Wie ist denn überhaupt der Plan? Was soll hinter dem Http-Server sitzen? Das müsste ja schon was mit state sein, also zB. nen servlet, was die Verbindungen offen halten kann. Und das läuft wohl auf den wenigsten billig-hostern... Wenn ich aber eh root hab um einen servlet-container zu installieren, dann kann ich dass doch auch mit nem einfachen socket-proxy machen? Oder halt den Mysql-Server für eine IP nach aussen aufmachen, notfalls per Firewall..

 

[tuxedo]

@Dante:

Das ganze soll auf 0815 Standardservern laufen. Wenn du dir die müge gemacht hättest mal die Projektseite zu öffnen, dann wüsstest du dass ich für die Serverseite ein kleines, aber feines PHP-Script nutze.

Ich bin mir durchaus bewusst dass das nur suboptimal ist, aber um "der breiten Masse" zu ermöglichen so eine DB zu benutzen und den Einsatz so einfach wie möglich zu machen, gabs für mich erstmal keinen anderen Weg. Die Performance OHNE ssl kann sich bereits jetzt schon sehen lassen (dank gzip geht jetzt noch mehr durch die Leitung). Die Geschwindigkeit ist quasi nur noch von der Downloadgeschwindigkeit des Clients abhängig.

Das offen halten der Verbindung geht mit PHP leider nicht. Dafür ist das Ding aber total easy zu benutzen. Der einzigtse, bis jetzt für mich gravierende Nachteil: Die Prepeared Statements haben keinen Geschwindigkeitsvorteil (die leben ja nur während einer Verbindung).

Das verwendete Protokoll produziert absolut minimalen Overhead (muss mal noch den Prozentualen Anteil ausrechnen...).

Dass es noch andere Wege gibt ist mir klar (rootserver, eigener tunnelserver, vpn, ssh, ....). Aber die wenigsten haben soetwas. Und diejenigen die sowas haben, setzen dann doch lieber gleich den originalen MySQL Connector/J ein und schauen selbst wie sie die Verbindung herstellen.

Zu dem Plan "was soll hinter dem Server sitzen" ... Naja, das Projekt ist schon soweit dass man es verwenden kann. D.h. der Plan ist nicht nur gemacht, sondern auch ausgeführt.

Es fehlt nur noch eine Verschlüsselung und etliche Methoden (die von den meisten JDBC-Anfängern vermutlich eh nie genutzt werden) die ausimplementiert werden müssen.

- Alex