Probleme mit MySQL Remotezugriff

[HeyJ]

Hi Kollegen,

ich kämpfe seit einigen Wochen schon mit einem - eigentlich ja nicht so dramatischen - Problem.

Kurz zum erklärten Ziel:

Direkter Zugriff auf die gesamte MySQL-Datenbank über Port 3306 auf unseren Dedizierten Windows Server von 1und1. Der Zugriff war/ist nur von unserer Festen IP über das Büro aus möglich. Alle anderen Anfragen auf diesen Port werden verworfen. Das hatte bis zu Crash so funktioniert und hätte auch nach unserem Server-Umzug so funktionieren sollen bzw. MUSS wieder funktionieren :-).

Die Ausgangslage:

aktuell hab ich diverse Server von 1und1 mit Windows am laufen (bitte keine Debatte darüber... :-)... Ich sag nur ASP und Co.). Wir wollen schlussendlich nur einen Server betreiben!

Bisher lief seit einigen Jahren ein Server 2003R2 x64 mit einer MySQL 5.1 Datenbank und etlichen Websites. Der Zugriff erfolgte vom Büro aus von diversen Rechner per ODBC und Access oder von unserem Intranet-Server und einigen ASP-Seiten aus. Nun wollte ich schon Anfang August ein Umzug auf ein modernes (und günstigeres, da "kleiner") Windows 2008R2 System wagen mit einem neuen MySQL 5.5 und dem IIS7.5. Es war quasi alles eingerichtet NUR den externen Zugriff konnte ich nie realisieren und ich weiß nicht warum. Ich habe mir die Finger wund gesucht. Ich will im Folgenden kurz erklären was ich geprüft habe bzw. wo das Problem liegt:

Beim externen Zugriff auf die MySQL-Datenbank mit z.B. HeidiSQL bekomm ich IMMER einen Socket-Fehler 10060 (Zeitlimit für Verbindung erreicht)

Bei der Überprüfung mit Wireshark (Filter: ip.src == 217.#.#.# or ip.dst == 217.#.#.#) seh ich ja auch definitiv die Anfragen.

Die Bindung von MySQL hab ich auch schon angepasst mit bind=87.#.#.#... Mit dem Tool CurrPorts von Nirsoft seh ich ja auch dass der Prozess mysqld auf entsprechendem Port und der entsprechenden IP wartet... Wenn ich bind deaktiviere ist die IP an der stelle dann nur 0.0.0.0

Wenn ich jetzt nicht völlig falsch gewickelt bin oder einen Denkfehler habe, müsste mysqld doch eigentlich auf DIESER IP auf meine ankommenden Anfragen reagieren oder?? Ich hab beim Setup und dem Assistenten auch z.B. ausgewählt dass Remotezugriffe möglich sein sollen. Das bewirkt aber glaube ich nur, dass ein root-User angelegt wird mit einem % für den Host.

Ich habe auch folgende Seite mal durchgeackert: MySQL :: MySQL 5.5 Reference Manual :: C.5.2.2 Can't connect to [local] MySQL server

Hat aber auch nichts gebracht

Ich hab wirklich schon viel versucht, bin aber irgendwie verzweifelt. Ich habe die Befürchtung dass ICH irgendwo den Fehler habe oder fabriziere, dass ich dieses Problem auf ALLEN 4 Servern habe die ich jetzt mehrfach mit Server 2003R2 und 2008R2 installiert habe. Zudem habe ich MySQL 5.5.17 sowie 5.1.59 getestet. Vor allem hat es ja schon zuvor funktioniert!! Eingerichtet hatte ich den bisherigen Server leider nicht (der zudem jetzt noch abge****t ist). Die damalige my.ini hab ich auch nicht mehr, weils mein Vorgänger einfach an der Stelle vergeigt hat (und hat zudem NICHT die InnoDB Files gesichert sondern nur die MyISAM :´-(

Ich würde mich wahnsinnig freuen wenn man mir helfen könnte. Evtl beiß ich mich ja auch nur an einem Verständnissproblem fest oder so...

VPN wäre sicher eine Variante, kommt aber momentan noch nicht in Frage.

Fränkische Grüße

Christian

PS: hier noch die my.ini ohne Kommentare... mit bind und natürlich ohne skip-networking!

[client]

port=3306


[mysql]

default-character-set=utf8


[mysqld]

port=3306

bind=87.#.#.#

basedir="D:/webapp/mysql55/"

datadir="D:/mysqldata/Data/"

character-set-server=utf8

default-storage-engine=MYISAM

sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

max_connections=160

query_cache_size=201M

table_cache=320

tmp_table_size=205M

thread_cache_size=8

myisam_max_sort_file_size=100G

myisam_sort_buffer_size=339M

key_buffer_size=316M

read_buffer_size=64K

read_rnd_buffer_size=256K

sort_buffer_size=256K

innodb_data_home_dir="D:/mysqldata/"

innodb_additional_mem_pool_size=13M

innodb_flush_log_at_trx_commit=1

innodb_log_buffer_size=7M

innodb_buffer_pool_size=613M

innodb_log_file_size=123M

innodb_thread_concurrency=18

Bearbeitet 2. November 2011 von HeyJ

[flashpixx]

das "bind" des Dämon ist wohl richtig gesetzt. Ist eine Firewall aktiv und richtig konfiguriert? Stimmen die Authentifizierungsdaten der User mit dem Du Dich anmeldet (Host / Usertabelle)?

Ein worst-case Tip wäre, kopiere Dir das "datadir" und setze einfach alles neu auf und nachdem Du den neuen mySQL installiert hast ersetzt Du das datadir (natürlich nur bei ausgeschalteten Dienst auf Dateiebene ersetzen)

[HeyJ]

Ist eine Firewall aktiv und richtig konfiguriert? Stimmen die Authentifizierungsdaten der User mit dem Du Dich anmeldet (Host / Usertabelle)?

Also Ich hab schon alles mögliche durchprobiert. Wie geschrieben sollten monentan KEINE Firewall aktiv sein. Wenn ichs richtig versteh, dürfte Wireshark ja auch keine Pakete anzeigen, wenn die Firewall blocken würde, oder??

Die Auth-Daten sind mit ziemlicher sicherlich korrekt. ich habs mit root-Usern versucht sowie mit Datenbank-Spezifischen Usern...

Ein worst-case Tip wäre, kopiere Dir das "datadir" und setze einfach alles neu auf und nachdem Du den neuen mySQL installiert hast ersetzt Du das datadir (natürlich nur bei ausgeschalteten Dienst auf Dateiebene ersetzen)

es ist ja nicht so als hätt ich alles schon 20 mal installiert... mysql 5.1 sowie mysql 5.5... mal leerer Datenbank so wie es der Setup-Assistent einrichtet, mal mit meinen gesicherten Daten...

ich versteh halt nicht, warum es sowas von gar nicht klappt... irgendwann zweifelt man an sich selbst

Gruß

Christian

[flashpixx]

Also Ich hab schon alles mögliche durchprobiert. Wie geschrieben sollten monentan KEINE Firewall aktiv sein. [...]

Die Auth-Daten sind mit ziemlicher sicherlich korrekt. ich habs mit root-Usern versucht sowie mit Datenbank-Spezifischen Usern...

Wenn Du es nicht sicher weißt, dann schaue es nach ("...sollte keine...", "...ziemlicher Sicherheit..."). Nur weil ein Dienst an eine IP gebunden wird, heißt das noch lange nicht, dass man mit ihm kommunizieren kann.

[HeyJ]

Wenn Du es nicht sicher weißt, dann schaue es nach ("...sollte keine...", "...ziemlicher Sicherheit..."). Nur weil ein Dienst an eine IP gebunden wird, heißt das noch lange nicht, dass man mit ihm kommunizieren kann.

Ja du hast schon recht, aber wie gesagt, wenn ich die Anfragen doch im Wireshark sehe, kommen Sie doch auch durch, oder irre ich mich?? :confused:

Gruß

Christian

[flashpixx]

Nein, man kann auch einzelne Anwendungen blockieren / einschränken. Außerdem liest Wireshark nur entsprechende Daten auf einem Interface mit, wenn eine Firewallregel den Verkehr in einer bestimmten Phase blockiert / verändert, dann würde man das nicht in Wireshark sehen. Eine Firewall besteht in den meisten Fällen aus mehreren Stufen und damit ist es entscheidet wo Wireshark und der Dienst die Daten abgreifen.

[HeyJ]

Also Lokal läuft zum aktuellen Zeitpunkt definitiv keine Firewall, nachdem ich keine installiert habe und die Windows-Firewall auf Eis liegt... die 1und1 Firewall hatte ich auch schon deaktiviert und greift ja VOR dem Interface und besitzt eine Regel die Anfragen auf Port 3306 von unserer Firmen-IP durchlässt. Diese Konfiguration lieft bisher schon so einige Jahre womit ich das also auch ausschließe.

Auf meinen Test-Systemen hab ich auch die Windows-Firewall von 2008R2 auch schon entsprechend konfiguriert oder abgeschaltet, aber es tut sich einfach nix

[flashpixx]

Also Lokal läuft zum aktuellen Zeitpunkt definitiv keine Firewall, nachdem ich keine installiert habe und die Windows-Firewall auf Eis liegt... die 1und1 Firewall hatte ich auch schon deaktiviert und greift ja VOR dem Interface und besitzt eine Regel die Anfragen auf Port 3306 von unserer Firmen-IP durchlässt. Diese Konfiguration lieft bisher schon so einige Jahre womit ich das also auch ausschließe.

Naja, zu sagen "das lief bisher immer so", ist schon etwas bedenklich. Aber ich würde jetzt einfach mal sagen, dass es kein Firewallproblem ist. Wäre die nächste Frage, ob das Problem an dem Interface liegt (Stichwort virtuelle Interfaces). Klappt ein Zugriff von lokal auf den Dienst? Klappt ein Zugriff von einem Rechner, der nicht im LAN ist? Ggf das Loglevel des Dienstes erhöhen, um mehr Infos zu bekommen. Kann es sein, dass evtl ein andere Prozess / Zombiprozess den Port blockiert (ggf falls der Dienst abgestürzt war)? Stimmen die Zugriffsrechte des Dienstes und der Verzeichnisse / Dateien, auf die der Dienst zugreift?

[HeyJ]

Servus,

ich habe einen Lichtblick!!! Ich habe vor ein paar Tage auch eine Anfrage im 1und1 Forum gestellt die jetzt vorhin beantwortet wurde...

Offensichtlich sind bei 1und1 alle Server mit einer Lokalen Gruppenrichtlinie konfiguriert in der ein IP-Filter konfiguriert ist. Quasi ein iptables unter Windows. Mir war bis gerade nicht bewusst, dass es sowas gibt, aber man lernt nie aus...

aber wie du schon richtig analysiert hattest, ist dort noch eine Instanz aktiv gewesen die IP-Anfragen NACH dem Wireshark verarbeitet und blockiert... das hat mir das Leben echt zur Hölle gemacht und erklärt auch, warum ich bei dem 1und1-Server auch kein Passiv-Mode zum laufen gebracht habe...

Echt zum ****en, dass einen der Premium-Support von der Hotline nicht ein einziges Mal auf so einen Sachverhalt aufmerksam gemacht hat... Immer nur "für Software geben wir keine Support"... :upps

Ich geb noch mal ein Update, wenn das hier als erfolgreich abgeschlossen gilt...

Gruß

Christian

[flashpixx]

Ich nutze Linux auf meinen System *scnr* da habe ich das Problem nicht (sorry, der musste sein).

Aber wenn es an der lokalen Richtlinie liegt, dann kann man das ja recht einfach lösen

[HeyJ]

Aber wenn es an der lokalen Richtlinie liegt, dann kann man das ja recht einfach lösen

Jap, es sieht so aus als wäre das gelöst...

Ein Problem hab ich aber noch immer nicht im Griff: den FTP-PASV-Mode (Passive Mode)...

Das müsste in dem IP-Sec Filter ja entsprechend konfiguriert werden, ich weiß nur nicht wie am besten. Ich kann scheinbar kein Port-Range freigeben... meinem Verständniss nach öffnet der FTP-Server auf Anfrage einen Ports zwischen 1024-65535 und meldet den entsprechenden Port via Port 21 an den Verbundenen Client... Ich kann aber ja schlecht all diese Ports einzeln freigeben und ein Konfigurieren auf beliebige eingehende Ports würde ja den IP-Filter überflüssig machen... oder?

Gruß

Christian

[flashpixx]

Das müsste in dem IP-Sec Filter ja entsprechend konfiguriert werden, ich weiß nur nicht wie am besten. Ich kann scheinbar kein Port-Range freigeben... meinem Verständniss nach öffnet der FTP-Server auf Anfrage einen Ports zwischen 1024-65535 und meldet den entsprechenden Port via Port 21 an den Verbundenen Client... Ich kann aber ja schlecht all diese Ports einzeln freigeben und ein Konfigurieren auf beliebige eingehende Ports würde ja den IP-Filter überflüssig machen... oder?

siehe File Transfer Protocol

Ich verzichte komplett auf FTP und nutze SSH, ggf mit Tunnel.