Zainstalowałem wystąpienie SQL Server 2008 Express na dedykowanym serwerze Windows 2008 Server hostowanym przez 1and1.com. Nie mogę połączyć się zdalnie z serwerem poprzez studio zarządzania. Podjąłem poniższe kroki i nie jestem w stanie zrealizować żadnych dalszych pomysłów. Przeszukałem witrynę i nie mogę znaleźć niczego innego, więc proszę wybacz mi, jeśli coś przeoczyłem, ale wariuję. Oto najważniejsze informacje.
Wystąpienie programu SQL Server działa i działa idealnie podczas pracy lokalnej.
W SQL Server Management Studio zaznaczyłem pole „Zezwalaj na zdalne połączenia z tym serwerem”
Usunąłem wszelkie zewnętrzne ustawienia zapory sprzętowej z panelu administracyjnego 1 i 1
Zapora systemu Windows na serwerze została wyłączona, ale tylko dla kopnięć dodałem regułę ruchu przychodzącego, która zezwala na wszystkie połączenia na porcie 1433.
W konfiguracji SQL Native Client włączony jest protokół TCP / IP. Upewniłem się również, że „IP1” z adresem IP serwera ma wartość 0 dla portu dynamicznego, ale usunąłem go i dodałem 1433 w zwykłym polu Port TCP. Ustawiłem również port TCP „IPALL” na 1433.
W konfiguracji SQL Native Client działa również przeglądarka SQL Server i
Próbowałem także dodać ALIAS w
Zrestartowałem serwer SQL po ustawieniu tej wartości.
Wykonanie polecenia „netstat -ano” na maszynie serwera zwraca a
TCP 0.0.0.0:1433 LISTENING UDP 0.0.0.0:1434 LISTENING
Wykonuję skanowanie portu z mojego komputera lokalnego i mówi, że port jest FILTROWANY zamiast SŁUCHANIA. Próbowałem także połączyć się z Management Studio na moim komputerze lokalnym i generuje błąd połączenia. Próbowałem następujących nazw serwerów z SQL Server i uwierzytelnieniem systemu Windows oznaczonym w zabezpieczeniach bazy danych.
ipaddress \ SQLEXPRESS, 1433
ipaddress \ SQLEXPRESS
adres IP
ipaddress, 1433
tcp: ipaddress \ SQLEXPRESS
tcp: ipaddress \ SQLEXPRESS, 1433
źródło
Odpowiedzi:
Myślę, że mogę powiedzieć dokładnie, na czym polega problem, spędziłem ponad 48 godzin, próbując rozwiązać ten problem. nic nie znalazłem w sieci. zdarza się również, że są z 1 i 1
spójrz na te ustawienia:
które otwiera pole ............... Właściwości filtru pakietów w dolnej części listy jest zaznaczone pole o nazwie:
które otwiera okno ............ Edytuj właściwości reguły Wybierz (ponownie) >> 'Zamknij MSDE (TCP / UDP)' Naciśnij Edytuj ...
które otwiera okno ................ Lista filtrów IP, a następnie zobaczysz listę portów tcp 1433, udp 1434 {To nasza lista portów w dół jako reguła blokująca ... ..}
Myślę, że tym, co należy zrobić, jest albo ...
zamknij ten ekran .. Filtr IP Lista na ekranie Edytuj właściwości reguły jest zakładka Akcja filtrowania, czy wystarczy zmienić tę opcję z Blokuj, aby zezwolić? (być może zmiana na zezwolenie pozwoli nam ponownie zaznaczyć opcję „Blokuj wszystko” - co brzmi bezpieczniej, ale faceci ze wsparcia powiedzieli, że istnieje znany błąd, więc może nie działać)
lub
we właściwościach filtru pakietów
po prostu odznacz regułę „Zamknij MSDE (TCP / UDP)”
może być konieczne odznaczenie reguły „Blokuj WSZYSTKO”, aby ją uruchomić
prawdopodobnie jest już za późno, aby ci to pomóc, ale mam nadzieję, że pomoże komuś innemu z tym samym problemem.
źródło
Po pierwsze, w studio zarządzania sprawdź zarządzanie, dzienniki serwera SQL \ bieżące - chcesz wyszukać komunikat „Serwer nasłuchuje na [„ dowolnym ”1433]. Jeśli nie, przejdź do uruchomienia, wszystkie programy, SQL Server 2008, narzędzia konfiguracyjne, menedżer konfiguracji serwera SQL. Wybierz „Konfiguracja sieciowa serwera SQL / protokoły dla MSSQLServer \ SQLExpress”. Upewnij się, że protokół TCP / IP jest włączony. Powinien być oparty na wynikach netstat -ano, ale ...
co najważniejsze - czy próbowałeś zalogować się przez klienta zdalnego?
?źródło
Możesz także wypróbować www.firebind.com. Może sprawdzić, czy jest jakiś blok portu TCP 1433 w kierunku wychodzącym w kierunku 1 i 1.
http://www.firebind.com/1433 przetestuje to natychmiast.
źródło
Ten sam ból głowy łączyłem się z SSMS z komputera klienckiego do zdalnego programu SQL Server. Wygląda na to, że lokalna zapora sieciowa blokowała przychodzące połączenie z serwerem. Problem został rozwiązany poprzez przypisanie reguły przychodzącej do SSMS dla zapory PC klienta. Jedynym miejscem, w którym znalazłem, jak to zrobić, było https://msdn.microsoft.com/en-us/library/cc646024(v=sql.120).aspx
To mi pomogło. Mam nadzieję, że ty też.
źródło
Czy jesteś w stanie telnet do portu 1433 ze swojej stacji roboczej? Jest to łatwy sposób ustalenia, czy masz połączenie sieciowe na tym porcie. Możliwe, że twój dostawca blokuje połączenie ze swoim sprzętem gdzieś wzdłuż linii.
Fakt, że widzisz port jako przefiltrowany, sprawia, że myślę, że blokują gdzieś poniżej linii. Możesz się z nimi skontaktować, ponieważ mogą nie chcieć zezwalać na zdalne łączenie się z serwerami SQL lub blokują dobrze znane porty. tcp / 1433 jest dobrze znanym portem i istnieje kilka robaków związanych z SQL Server, które atakują go bezpośrednio.
źródło
wpisz „netstat -an” na serwerze, aby sprawdzić, czy port 1433 faktycznie nasłuchuje. Upewnij się także, że konto użytkownika, którego używasz, jest włączone, a także „Uwierzytelnianie SQL” jest włączone. zadbaj także o ustawienia „SQL Configuration Manager”. Ponadto zezwól na port 1433 jako wyjątek w zaporze systemu Windows. Zasadniczo, jeśli nie powiedziałeś serwerowi SQL, aby zezwalał na połączenia zdalne, to nie będzie.
źródło
Czy agent serwera SQL działa? jeśli nie, którą wersję serwera SQL posiadasz?
Przejrzyj różnicę między różnymi wersjami.
http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx
Jeśli masz wersję Express lub Web, są one wyłączone i nie można ich uruchomić.
źródło
Szalony pomysł, czy Twoja nazwa użytkownika i hasło są poprawne? Czy logujesz się przy użyciu uwierzytelniania systemu Windows lub programu SQL Server?
źródło
Poszukaj łączności na swoim SQL-Express. Aktywuj TCP / IP. Upewnij się, że port jest skonfigurowany na 1433 w SQL-Express. Czy zainstalowałeś nazwaną instancję?
Ten port musi być przesłany o 1 i 1 do Twojej instancji serwera SQL.
Przy okazji sprawdź swoją stronę o porcie 1433. Jeśli twój dostawca go zablokuje, nie masz szans.
źródło
Co dla mnie zadziałało:
http://blogs.msdn.com/b/sqlexpress/archive/2005/05/05/415084.aspx
W szczególności stwierdziłem, że problem polegał na przypisaniu żądanego portu w sekcji IPALL ustawień TCP / IP. Wcześniej było puste i nie myślałem, że będę musiał wprowadzić tutaj wartość, kiedy usunąłem bity „dynamicznego portu”.
źródło