Недавно настроенный MSSQL2008, TIME_WAIT, но не ESTABLISHED?

Windows 2008 R2, стандарт. Нет брандмауэра локально на нем. Новая настройка, потому что на старом SQL2000 два диска умерли (или это может быть контроллер рейда?) Одновременно. К счастью, у меня были свежие резервные копии.
Базы данных были восстановлены и применен SP2 для SQL2008.

Я вижу различные хосты, пытающиеся установить сеанс, но сайты (клиентов) не работают, и я не вижу ожидаемых установленных сеансов. Wireshark показывает полное трехстороннее рукопожатие. Так как это клиентские компьютеры подключаются, я не могу войти в них и перезапустить пулы приложений.

Что на земле может быть причиной этого?

No.     Time        Source                Destination           Protocol Info
  1 0.000000    1.2.5.127         1.2.6.133         TCP      desktop-dna > ms-sql-s [SYN] Seq=0 Win=65535 Len=0 MSS=1380 SACK_PERM=1

Frame 1: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Cisco_31:5e:09 (00:26:0b:31:5e:09), Dst: Vmware_b7:00:05 (00:50:56:b7:00:05)
Internet Protocol, Src: 1.2.5.127 (1.2.5.127), Dst: 1.2.6.133 (1.2.6.133)
Transmission Control Protocol, Src Port: desktop-dna (2763), Dst Port: ms-sql-s (1433), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Info
  2 0.000123    1.2.6.133         1.2.5.127         TCP      ms-sql-s > desktop-dna     [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1

Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
Ethernet II, Src: Vmware_b7:00:05 (00:50:56:b7:00:05), Dst: Cisco_31:5e:09 (00:26:0b:31:5e:09)
Internet Protocol, Src: 1.2.6.133 (1.2.6.133), Dst: 1.2.5.127 (1.2.5.127)
Transmission Control Protocol, Src Port: ms-sql-s (1433), Dst Port: desktop-dna (2763), Seq: 0, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Info
  3 0.000884    1.2.5.127         1.2.6.133         TCP      desktop-dna > ms-sql-s [ACK] Seq=1 Ack=1 Win=65535 Len=0

И netstat

TCP    1.2.6.133:1433     1.2.2.98:26895     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26912     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26918     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.2.98:26931     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2736     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2737     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2738     TIME_WAIT       0
TCP    1.2.6.133:1433     1.2.5.127:2739     TIME_WAIT       0

Изменить: Кажется, что это базы данных master/msdb/model, которые не могут быть восстановлены из-за несоответствия версий.

Источник

2 ответа

Решение

Проблема заключалась в том, что база данных master не могла быть импортирована, поэтому, по сути, входы в систему не восстанавливались.

Источник

Вы смотрите на это на основании сообщений о сбоях или потому, что трассировка сети выглядит забавно?

Если вы можете получить одновременный захват на сервере и на уязвимом клиенте, это скажет вам больше.

Возможные причины для успешного трехстороннего рукопожатия, но ничего после этого:

  • TCP Offload Engine включен, и сетевой адаптер работает в режиме дымохода
    • (TOE- использовать netsh int tcp sh gl проверить, думает ли ОС, что разгрузка TCP выключена или включена, но учтите, что драйвер NIC должен также включить его, чтобы он работал)
    • Просто заметил запись VMWare в трассировке; TOE еще не работает на виртуальных машинах.
  • Проблемы MTU между сервером и клиентом
  • Сервер не отвечает, или
  • Клиент никогда не отправляет начальную команду
Источник
Другие вопросы по тегам