15
SQL Server unter Port1433 nur aus einem Netzwerk erreichbar
Wir haben ein Problem mit dem Zugriff auf unseren SQL Server
Wir haben 3 Standorte mit 3 verschiedenen Netzsegmenten
Der SQL Server ist im Netzsegment Zentrale. Die Clients in diesem Segment haben Zugriff auf den SQL Server.
Firewall ist offen auf Port 1433. Alle Einstellungen ok
IPall eingestellt auf Port 1433
In Standort A und Standort B kann der Server von den Clients nicht erreicht.
Die Firewalls stehen in den VPN Kanälen alle auf "Any"
getestet wurde auch mit telnet In der zentrale ok an den Standorten keine Verbindung möglich.
mit nmap Scan durchgeführt hier wird uns auch der offene Port angezeigt beim entsprechenden Server
Dateizugriff auf den Server geht, Remotedesktop geht, Namensauflösung über all an allen 3 Standorten gegeben.
Hat hier noch jemand eine Idee dazu wo man noch nachsehen kann.
Wir haben 3 Standorte mit 3 verschiedenen Netzsegmenten
Der SQL Server ist im Netzsegment Zentrale. Die Clients in diesem Segment haben Zugriff auf den SQL Server.
Firewall ist offen auf Port 1433. Alle Einstellungen ok
IPall eingestellt auf Port 1433
In Standort A und Standort B kann der Server von den Clients nicht erreicht.
Die Firewalls stehen in den VPN Kanälen alle auf "Any"
getestet wurde auch mit telnet In der zentrale ok an den Standorten keine Verbindung möglich.
mit nmap Scan durchgeführt hier wird uns auch der offene Port angezeigt beim entsprechenden Server
Dateizugriff auf den Server geht, Remotedesktop geht, Namensauflösung über all an allen 3 Standorten gegeben.
Hat hier noch jemand eine Idee dazu wo man noch nachsehen kann.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 23015559235
Url: https://administrator.de/contentid/23015559235
Printed on: April 27, 2024 at 11:04 o'clock
15 Comments
Latest comment
Die Firewall am SQL Server muss Port 1433 für alle Netze erlauben, nicht auf dem Client. Das ist nicht ganz eindeutig formuliert.
Hat der SQL Server ein Gateway in die Netze A und B?
Hat der SQL Server ein Gateway in die Netze A und B?
Es ist auf der Serverseite der Port 1433 geöffnet
Serverfirewall und SQL Konfigurator ipall auf Port 1433 dynamische Ports abgeschalten
Serverfirewall und SQL Konfigurator ipall auf Port 1433 dynamische Ports abgeschalten
Gateway ja an allen 3 Standorten Zentrale eine Firewall mit VPN Verbindungen wireguard zu Standort A Firewall und Standort B Firewall.
An allen Standorten ist die Firewall jeweils das Gateway
An allen Standorten ist die Firewall jeweils das Gateway
wie @ukulele-7 richtig schreibt:
Zudem in den Servereigenschaften desSQL-Servers die Netze freigeben, unabhängig von Firewalls!
Zudem in den Servereigenschaften desSQL-Servers die Netze freigeben, unabhängig von Firewalls!
1
Was meinst du damit wo finde ich die?
Habt ihr mir da einen screenshot wo ich das finde
SQL managment studio ? oder SQL Konfigurator?
Zum einen kannst/musst du im Konfigurator die Netze freischalten, zum anderen werden jedem Benutzer berechtigte Netze zugeordnet ...
1
SQL Server Firewall ist eigentlich per Default TCP 1433 für alle Profile und Adressen offen, es sei denn beim Ersteinrichten hat man das verändert. Gleiches gilt für TCP/IP Einstellungen/IP-Adressen.
@autoPM24 kann man den SQL Server z.B. via Ping erreichen? Geht das umgekehrt auch?
@autoPM24 kann man den SQL Server z.B. via Ping erreichen? Geht das umgekehrt auch?
2
Also wenn Ping geht (aus Subnetz zum Server und zurück) dann wäre auf jeden Fall kein Routing Problem gegben. DNS wirst du vermutlich auch getestet haben, muss natürlich im Subnetz auch richtig auflösen. Windows Firewall scheint richtig konfiguriert, die kannst du aber mal testweise am Server komplett abschalten um zu sehen ob es sich anders verhält.
Wie @DerMaddin schon schreibt muss am SQL Server eigentlich nur der Port auf 1433 fix gesetzt sein und die Verbindung läuft. Auch Benutzerrechte sind vermutlich eher nicht in irgendeiner Form auf Subnetze eingeschränkt, testest du als SA?
Wie @DerMaddin schon schreibt muss am SQL Server eigentlich nur der Port auf 1433 fix gesetzt sein und die Verbindung läuft. Auch Benutzerrechte sind vermutlich eher nicht in irgendeiner Form auf Subnetze eingeschränkt, testest du als SA?
Hier noch eine Möglichkeit es zu testen SQL Verbindungstest
Nach den bisherigen Beschreibungen des TO soll der Zugriff von den Standorten A und B auf alles andere als dem SQL Server funktionieren, nur eben nicht auf die Datenbank, während in der Zentral alles direkt funktioniert. Sofern an den Standorten hinsichtlich DNS alles richtig aufgelöst wird, bleibt für mich eigentlich nur das Ruleset auf den Firewalls der Standorte und der Zentral als Quelle des Problems übrig. Denn ich gehe davon aus, dass die Standorte zwar per Site-to-Site an die Zentrale angebunden sind, aber ansonsten direkt ins Internet gehen - also ein Splittunneling.
Hier könnte je nach Firewall ein oder mehrere Rules zusammen eine Seitenwirkung haben. Es gibt außerdem meiner Erfahrung nach gelegentlich das zunächst unerklärliche Phänomen, dass eine gedanklich zutreffend eingerichtete Erlaubnis praktisch dann doch nicht funktioniert und der Traffic irgendwie hängen bleibt / verworfen wird. Daher sollte der TO die Protokolldaten der Firewall genau inspizieren und gegebenenfalls das Protokollniveau auf ausführlich(er) setzen. Dort sieht er ganz genau, ob der Traffic vom jeweiligen Standort zum SQL Server durchkommt und aufgrund welcher Rule es scheitert. Höchstwahrscheinlich muss hier am Ruleset nachgearbeitet werden, damit es wirklich klappt.
Natürlich gilt das ebenso für die umgekehrte Richtung von der Zentrale / SQL Server zum jeweiligen Client am Standort.
Viele Grüße
HansDampf06
Hier könnte je nach Firewall ein oder mehrere Rules zusammen eine Seitenwirkung haben. Es gibt außerdem meiner Erfahrung nach gelegentlich das zunächst unerklärliche Phänomen, dass eine gedanklich zutreffend eingerichtete Erlaubnis praktisch dann doch nicht funktioniert und der Traffic irgendwie hängen bleibt / verworfen wird. Daher sollte der TO die Protokolldaten der Firewall genau inspizieren und gegebenenfalls das Protokollniveau auf ausführlich(er) setzen. Dort sieht er ganz genau, ob der Traffic vom jeweiligen Standort zum SQL Server durchkommt und aufgrund welcher Rule es scheitert. Höchstwahrscheinlich muss hier am Ruleset nachgearbeitet werden, damit es wirklich klappt.
Natürlich gilt das ebenso für die umgekehrte Richtung von der Zentrale / SQL Server zum jeweiligen Client am Standort.
Viele Grüße
HansDampf06
1
UDP-Port 1434?
Ansonsten mal bei MS unter Konfigurieren der Windows-Firewall für den SQL Server-Zugriff nachschauen, ob da noch was schlaues zur Firewall steht, was bei Euch sinnvoll ist.
Gruß, Mad Max
Ansonsten mal bei MS unter Konfigurieren der Windows-Firewall für den SQL Server-Zugriff nachschauen, ob da noch was schlaues zur Firewall steht, was bei Euch sinnvoll ist.
Gruß, Mad Max
Problem ist gelöst!
In der zentrale im lokalen Netz ist der SQL Server wie einegerichtet unter seinem Instanznamen erreichbar und unter dem Servernamen.
Beispiel Instanz SQLXXXXXEPL und Servername SQLXXXXXEPL01
In den Standorten ist dies nur über den Servernamen möglich SQLXXXXXEPL01 möglich.
Danke für die Hilfe
Gruß Paul
In der zentrale im lokalen Netz ist der SQL Server wie einegerichtet unter seinem Instanznamen erreichbar und unter dem Servernamen.
Beispiel Instanz SQLXXXXXEPL und Servername SQLXXXXXEPL01
In den Standorten ist dies nur über den Servernamen möglich SQLXXXXXEPL01 möglich.
Danke für die Hilfe
Gruß Paul
Bitte auch den Beitrag als gelöst markieren.