PythonJ
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Доброго дня, коллеги.
Ситуация следующая:
Есть у нас сервер (W2K8R2), на котором крутится MSSQL (2008 Express, TCP/IP включен). Комп в домене. Включена смешанная авторизация. Для спецов, кто по сетям, а не по MSSQL, поясню - смешанная авторизация работает по паре логин/пароль через соединение на порт, минуя доменную аутентификацию. Брэндмауэр отключен, все открыто. Доступ админа к этому серверу есть.
Есть удаленный терминальный сервер (1С-клиент, 1С-сервером работает другая машина, но это к делу не относится).
С этого самого терминального сервера до нашего MSSQL линк идет через шлюзы. Все пакеты идут в обе стороны, пинг идет, удаленный реестр, виндовый SMB, да все подряд, кроме MSSQL на родном 1433 порту. Перевешиваю со своей стороны MSSQL на другой порт - связь есть. На дефолтовом 1433 - глухо. При этом если ткнуться с любой машины в своей подсети (на порт 1433 по логину/паролю), то связь с сервером MSSQL есть. То есть порт открыт. К удаленному серверу админ-доступа нет. Брэндмауэр на нем отключен, пользовательские права позволяют это видеть.
Шлюзы - один с нашей стороны и пара на удаленной стороне. К нашим шлюзам у меня лично административного доступа прямого нет, но в случае необходимости, товарищ, который за них отвечает, доступ мне даст.
Админы со стороны терминалки - ребята очень проблемные, их пинать только через руководство сверху. Хотелось бы перед этим убедиться, что проблема не с нашей стороны. Как это наверняка сделать, посоветуйте, кому что в голову придет? Шлюзы щупать по очереди, или что?
Могу выключить MSSQL и повесить на прослушку порта любой другой софт, чтобы проверить. Подскажите только, какой.
Если что-то недостаточно пояснил, скажите, что. Заранее спасибо.
П.С. Собственно, я почти уверен, что где-то по дороге порт 1433 режется, но практика показывает, что излишняя самоуверенность приносит только вред. К самому MSSQL это отношение вряд ли имеет, поэтому кидаю в общую ветку. Возможно, ошибаюсь. |
