SQL Server -

але якщо ці порти закриті на файрволі, то ці товариші можуть прислухатися скільки завгодно, все одно нічого зовні вони не почують. Як приклад спробуємо створити прилінкований сервер на 192.168.0.2 з машини 192.168.0.1:
if exists( select 1 from sys . servers where name = 'Denalium' ) exec sp_dropserver @server = 'Denalium' , @droplogins = 'droplogins'
exec sp_addlinkedserver @server = N'Denalium' , @srvproduct = N'' , @provider = N'SQLNCLI' , @datasrc = N'192.168.0.2'
exec sp_addlinkedsrvlogin @rmtsrvname = 'Denalium' , @locallogin = null, @rmtuser = 'sa' , @rmtpassword = 'passw0rd'
exec sp_tables_ex @table_server = 'Denalium' , @table_catalog = 'Adventure Works 2008R2'
Останній оператор завершується з помилкою:
Msg 7399, Level 16, State 1, Procedure sp_tables_ex, Line 41
The OLE DB provider "SQLNCLI10" для linked server "Denalium" повідомлено про помилку. Provider did not give any information про the error.
Msg 7303, Level 16, State 1, Procedure sp_tables_ex, Line 41
Неможливо започаткувати цільовий ресурс даних об'єкта OLE DB підтримувача "SQLNCLI10" для linked server "Denalium".
Перш, ніж грішити на провайдера, рядок з'єднання, автентифікацію, еккаунт, під яким працює SQL Server ний сервіс, недолік прав, інопланетян, необхідно переконатися, що SQL Server 192.168.0.1 може банально достукатися на SQL Server 192.168.0.2. Дійсно, якщо з 192.168.0.1 пропінгувати порт 1433 на 192.168.0.2:

ми бачимо, що його закрито. У даному випадку використовувалася стародавня Microsoft овська тула PortQry, яку можна завантажити з Microsoft Downloads, що також згадувалася в попередній серії. PortQryможе використовуватися як найпростіший безкоштовний портовий сканер. Наприклад, можна передати список портів, які використовуються SQL Server і його компонентами (див. у минулій серії) і подивитися, хто з них відкритий, хто ні:
c:\temp\portqryv2\portqry.exe -n 192.168.0.2 -p TCP -o 1433,1434,80,443,4022,21,137,138,139,135,2383,2382
c:\temp\portqryv2\portqry.exe -n 192.168.0.2 -p UDP -o 1434,500,4500

Можна передати діапазон портів: c:\temp\portqryv2\portqry.exe -n 192.168.0.2 -p TCP -r 137:139 і т.д.
Виникає питання - як дізнатися, який порт потрібно відкрити SQL Server (щоб створити прилінкований сервер, налаштувати дзерклювання, поспілкуватися з сервіс-брокером, . ). Спочатку варто подивитися на Рис.1, щоб зрозуміти, чого хоче SQL Server , тобто. за якими портами він слухає = очікує отримати комунікацію. Але, по-перше, хотівок може бути багато, по-друге, не всі вони мають явне відношення до SQL Server, як, наприклад, порти 135, 80 і т.д. Більш надійний спосіб - це включити журналування на файрволі, виконати дію і подивитися, які порти йшло (намагалося пройти) взаємодія. Для початку варто переконатися, що причина справді криється в закритих портах. На файрволі 192.168.0.2 йду до Control Panel -> Administrative Tools -> Windows Firewall with Advanced Security (або wf. msc з командного рядка); встаю в лівій панелі на корінь і з контекстного меню або з правої панелі вибираємо Properties. У діалоговому вікні властивостей, що відкрилося, я вибираю закладку Private Profile , тому що з'єднання з 192.168.0.1 в моєму випадку відноситься до цього профілю, і відключаю для нього Windows Firewall :

Тепер sp _ tables _ ex на прилінкований сервер працює:

Значить,проблема дійсно в тому, що на файрволі 192.168.0.2 перекрито якісь необхідні порти. Залишилося зрозуміти які. Для цього на Рис.4 включаю назад файрвол на 192.168.0.2 у профілі Private, натискаю кнопку Customize у секції Logging і включаю журналування знехтуваних мережевих пакетів



Назви колонок наводяться у верхній строчці: дата, час, дія ( DROP означає, що пакет був відкинутий), протокол ( TCP , UDP , ICMP , …), з якого IP йшов пакет, на який, з якого порту, на який розмір пакет і т.д. У колонці Path вказується напрямок. RECEIVE у разі означає, що стосовно 192.168.0.2 це була вхідна комунікація. Спроба інтенсивного спілкування по порту 500 на початку - це IPSec. Залишається 1433 у трьох останніх рядках, де SSMS з 192.168.0.1 безуспішно б'ється про файрвол на 192.168.0.2, намагаючись достукатися до тамтешнього SQL Server. Варто включити 1433 на 192.168.0.2:
netsh advfirewall firewall add rule "SQL Srv" dir=in action=allow enable=yes profile=private protocol=tcp remoteip=192.168.0.1 localport=1433