Frage

Ich habe zum ersten Mal in ein bestehendes Netzwerk über VPN verbunden. Ich kann die IP-Adresse anpingen, die von dem SQL Server von dem VPN-Client verwendet wird, aber SSMS keine Verbindung mit dem SQL Server. Ich bin mit dem richtigen Login-ID und Passwort.

Warum konnte das passieren? Irgendwelche Ideen?

Danke

War es hilfreich?

Lösung

Auf einer Standardinstanz, hört SQL Server auf TCP / 1433 standardmäßig aktiviert. Dies kann geändert werden. Auf einer benannten Instanz, wenn nicht anders konfiguriert, überwacht SQL Server auf einem dynamischen TCP-Port. Was das bedeutet ist, sollte Server feststellen, dass die Port verwendet SQL ist, wird es eine andere TCP-Port auswählen. Wie Kunden finden in der Regel den richtig Port im Fall einer benannten Instanz ist durch Gespräche mit dem SQL Server-Listener Service / SQL-Browser. Das hört auf UDP / 1434 und kann nicht geändert werden kann. Wenn Sie eine benannte Instanz haben, können Sie einen statischen Port konfigurieren und wenn Sie eine Notwendigkeit, die Kerberos-Authentifizierung / Delegierung zu verwenden, sollten Sie.

Was Sie bestimmen müssen, ist, was Port SQL Server abhört. Dann müssen Sie mit Ihrem networking / Sicherheit Leute bekommen, um festzustellen, ob sie die Kommunikation mit diesem Port über VPN ermöglichen. Wenn sie sind, wie angegeben, überprüfen Sie die Firewall-Einstellungen. Einige Systeme haben mehrere Firewalls (mein Laptop ist ein Beispiel). Wenn ja, müssen Sie alle Firewalls auf Ihrem System überprüfen.

Wenn alle die korrekt sind, überprüfen Sie die Server keine IPSEC Politik, die über IP-Adresse Zugriff auf die SQL Server-Port beschränkt. Dass auch zur Folge haben könnten Sie blockiert werden.

Andere Tipps

Wenn mir dies geschieht, ist es, weil DNS nicht richtig funktioniert. Versuchen Sie es mit der IP-Adresse anstelle des Servernamens in der SQL Server-Anmeldung.

Stellen Sie sicher, dass SQL Server für die TCP / IP aktiviert ist (es jemand haben kann deaktiviert)?

Dies wird Ihnen auch die Portnummer der SQL-Instanz verwendet überprüfen / verifizieren helfen (falls jemand änderte es von dem Standard von Port 1433).

Offensichtlich Port 1433 (oder was auch immer Port SQL hört auf) von allen Firewalls zwischen Ihrem Gerät entsperrt werden muss, und das Feld SQL auf ausgeführt wird.

SQL-Netzwerk-Konfiguration zu überprüfen (erfordert SQL Server Client Tools installiert ist): Start -> Programme -> SQL Server 200x -> Konfigurationstools -> SQL Server Configuration Manager

Verbinden Sie

an der Maschine, die Sie benötigen, dann erweitern Sie den Baum Artikel (LHS) „SQL Server Network Configuration“, dann Instanz auswählen. Shared Memory, Named Pipes, TCP / IP und VIA - Sie sollten vier Optionen. Sie können das TCP überprüfen / IP in dem RHS-Fenster aktiviert ist.

Wenn Sie einen Doppelklick auf TCP / IP und die Registerkarte „Erweitert“ getroffen, können Sie auch die Portnummer.

Andere Gedanken .. Verwenden Sie SQL-Authentifizierung oder Windows (Domain) Authentifizierung?

  • Wenn die SQL-Authentifizierung (die ich nehme an, Sie gegeben werden unter Verwendung der Sie Benutzername und Passwort), sind Sie sicher, dass die SQL-Instanz Sie eine Verbindung herstellen Modus-Authentifizierung aktiviert gemischt hat? Wenn nicht, müssen Sie sich als Administrator verbinden und die Standardsicherheitseinstellungen ändern SQL-Authentifizierung zu ermöglichen.

  • Wenn die Windows-Authentifizierung, könnte Ihr Netzwerk möglicherweise mit Kerberos werden? Man würde denken, die VPN-Anmeldeinformationen würden für den Handshake verwendet werden. Ich würde überprüfen Sie Ihre Konten entsprechende Anmelderechte haben.

Überprüfen Sie, ob der Port, auf dem SQL Server verwendet, wird nicht durch entweder Ihre Firewall oder VPN blockiert werden.

Ich hatte auch dieses Problem, wenn die Ferne über das Hamachi VPN zu verbinden versucht. Ich hatte alles im Internet zur Verfügung (einschließlich diesen post) versucht, und es immer noch nicht funktioniert. Beachten Sie, dass alles funktionierte gut, wenn die gleiche Datenbank auf einem Computer in meinem lokalen Netzwerk installiert wurde. Schließlich konnte ich Erfolg mit dem folgende Update erreichen: auf dem entfernten Rechner, aktivieren Sie die IP-Adresse auf dem TCP / IP-Protokoll, etwa so:

Auf dem Remote-Computer, starten Sie SQL Server Configuration Manager, SQL Server-Netzwerkkonfiguration erweitern, wählen Sie "Protokolle für SQLEXPRESS" (oder "MSSQLSERVER") mit der rechten Maustaste auf TCP / IP, auf dem resultierenden Dialogfeld auf die IP gehen Register Adressen, und stellen Sie sicher, dass das „IP1“ Element Active=Yes und Enabled=Yes ist. Notieren Sie sich die IP-Adresse (für mich war es nicht notwendig, diese zu ändern). Dann stoppen und die SQL Server-Dienste starten. Danach wird sichergestellt, dass der Firewall auf der entfernten Maschine ist entweder deaktiviert oder eine Ausnahme für Port 1433 erlaubt, die sowohl das lokale Subnetz und das Subnetz für die im vorigen Dialogbox vermerkten Adresse enthält. Auf Ihrem lokalen Rechner sollten Sie, indem Sie den Namen des Servers 192.168.1.22\SQLEXPRESS (oder [ip address of remote machine]\[SQL server instance name]) anschließen können.

Ich hoffe, das hilft.

Sie nicht die UDP-Port offen / VPN-weitergeleitet haben kann, es ist die Portnummer 1433.

Trotz Client-Protokoll Namen "TCP / IP", mssql verwendet UDP für Bit-Banging.

SQL Server verwendet die TCP-Port 1433. Dies ist wahrscheinlich entweder durch den VPN-Tunnel oder durch eine Firewall auf dem Server blockiert wird.

Beim Anschluss von jeder Nachricht über VPN VPN-Server geht, und es könnte nicht Ihre Nachrichten an diesem Port SQL Server der Spedition arbeitet.

Versuchen

disable VPN Einstellungen-> Einstellungen-> TCP / IP Eigenschaften-> Erweitert-> Standard-Gateway im Remote-Netzwerk verwenden.

So können Sie zunächst versuchen, lokale IP von SQL Server zu verbinden und nur dann Server verwenden VPN Sie weiterleiten

Ich habe dieses Problem viel mit Citrix Access Gateway. Ich in der Regel einen Timeout-Fehler erhalten. Wenn Sie auf die Datenbank von einem Client auf dem Netzwerk verbinden können, aber nicht von einem Remote-Client über VPN können Sie die meisten Vorschläge vergessen hier gegeben, weil sie alle Adressserverseitige Probleme.

Ich bin in der Lage zu verbinden, wenn ich das Timeout von der Standardeinstellung (15 Sekunden) bis 60 Sekunden zu erhöhen, und für eine gute Maßnahme, zwinge das Protokoll TCP / IP. Diese Dinge können auf dem Bildschirm Optionen des Login-Dialog durchgeführt werden:

`

Dies ist, was mein Verbindungsproblem für den Zugriff auf dem SQL Server 2012-Datenbank über VPN Fest

Mit dem SQL Server 2012 Configuration Manager,

Ich ging in die SQL Server-Netzwerkkonfiguration

geklickt hat dann auf die neuen Server-Instanz und das TCP / IP-Protokoll doppelgeklickt [Ich hatte auch vorher diese Option aktiviert und neu gestartet wird den Server, aber das hat noch nicht beheben]

nun, dass die TCP / IP aktiviert wurde, bemerkte ich, dass alle IP-Port-Steckplatz in den ‚IP-Adressen‘ Reiter des TCP / IP-Eigenschaften erweiterten Dialog auf Aktiviert gesetzt wurde = Nein.

Ich war neugierig, warum meine neue Installation alle diese IP-Steckplätze auf NO gesetzt, anstatt Ja, also habe ich sie nur auf YES.

Nun ist die Verbindung zum Server über VPN funktioniert gut, ich habe keine Portnummern ändern.

Hinweis: Ich hatte auch SQL Server 2008 Standard aus dem Visual Studio 2010 deinstalliert, aber ich glaube nicht, dass eine direkte Auswirkung auf die TCP / IP-Situation hatte. Ein Kollege sagte mir, die die 2008 und 2005 Anlagen, die mit Visual Studio kommen mit SQL 2012 stören können.

Solange Sie das Firewall-Set haben Sie den Port, die SQL Server-Instanz verwendet, alles, was Sie tun müssen, damit ist Datenquelle von =Server name ändern =IP,Port

dh in der Verbindungszeichenfolge so etwas wie diese verwendet werden.

Data Source=190.190.1.100,1433;

Sie sollten nicht ändern auf der Clientseite müssen alles.

Ich habe dieses Problem auch mit SQL Server 2017.

Ich bin auf dem gleichen Netzwerk wie der Server über VPN und kann es ping. Nachdem er frustriert, dass keine Authentifizierungsmethode funktionieren würde - stellte ich einen SSH-Server auf dem SQL-Server auf - und ich war in der Regel verbinden kann. Dies bestätigte der richtige Anschluss wurde aus irgendeinem Grunde nicht getroffen zu werden. Ich habe sogar eine neue Benutzerkonten, Domänenkonten, Firewall prüft an beiden Enden, etc ...

Die Lösung für mich war: 1. Stellen Sie Anschluss an streng TCP / IP auf SSMS verwenden 2. Verwenden Sie eine benutzerdefinierte Zeichenfolge an den Standard-Port-zu-Punkt (zB: Datenquelle = 192.168.168.166,1433;)

Alle anderen Kommentare über bisher nicht gearbeitet. Es sieht aus wie es zwingend notwendig war, den Hafen zu schließen (obwohl sein Standard).

Wenn Sie SQL Server 2005 verwenden, SQL Server-Browser-Dienst starten erste

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top