SQL Server прив'язується до адреси VPN, якої немає під час завантаження

Простежте невдале прив'язування SQL Server від журналу запуску до фактичного слухача, а потім дайте клієнтам стабільну приватну адресу замість адреси з пулу VPN.

Прочитайте в журналі SQL Server рядок про невдале прив'язування, поки служба ще працює, і ви знайшли залежність від порядку завантаження, а не збій. Саме це поєднання і є підказкою: ядро запустилося раніше, ніж на машині з'явилася адреса, на якій йому було наказано слухати. VPN-адаптер, що піднімається після входу, — погана передумова для бази даних без нагляду, тому простежте збій у тому порядку, у якому його бачить ядро.

Почніть із журналу запуску, а не з клієнта

Відкрийте журнал помилок екземпляра і прочитайте записи навколо ініціалізації мережі, а не лише останній рядок. Ядро повідомляє, які адреси воно пробувало і які протоколи ввімкнуло, і цей запис з часу до підключення будь-якого клієнта. Тепер подивіться, що існує на хості просто зараз. Якщо інтерфейс, якому належить налаштована адреса, з'являється лише після входу користувача та запуску клієнта, адреси під час завантаження не було і збій прив'язування повністю пояснений.

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixOrigin
Get-Content 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG' -Tail 40

Налаштуйте шлях екземпляра під своє встановлення і прочитайте список інтерфейсів, перш ніж робити висновки. Адреса, яка існує, але належить не тому адаптеру, — це інша проблема, ніж адреса, якої ще немає.

Пройдіть порядок прив'язування, якого ядро справді дотримується

Ядро читає конфігурацію слухача, а потім просить операційну систему прив'язати. Якщо адреса в цей момент не локальна, прив'язування для цієї адреси не вдається, хоча решта екземпляра може продовжувати працювати нормально. Тому інші протоколи або інші адреси можуть і далі працювати, і тому «SQL Server лежить» — неправильний підсумок. Збережіть точну кінцеву точку з журналу: адресу, порт і протокол, бо виправлення залежить від того, що з цих трьох неправильно.

Перезапуск служби після появи адаптера зазвичай зробить слухач успішним, і це саме пастка. Він доводить залежність, а не усуває її, і обриває кожного підключеного користувача щоразу, коли тунель перепідключається.

Читайте слухача так, як його читає ядро

У SQL Server Configuration Manager відкрийте властивості TCP/IP екземпляра і зверніть увагу на параметр Listen All, перш ніж редагувати окремі адреси. Коли Listen All має значення Yes, значення Enabled для окремих адрес ігноруються, тому їх редагування нічого не змінює з того, що використовує слухач. Запишіть три речі по порядку: адресу, яку ви збираєтеся обслуговувати, порт і чи має слухач охоплювати всі адреси чи лише одну. Потім застосуйте зміну через підтримувану процедуру перезапуску і прочитайте наступний журнал запуску, щоб підтвердити, що ядро прив'язало те, що ви просили.

Прослуховування на всіх адресах — не контроль доступу. Якщо широкий слухач справді потрібен, кожному доступному інтерфейсу потрібне власне рішення щодо міжмережевого екрана й авторизації бази даних, включно з будь-яким інтерфейсом, спрямованим в інтернет.

Дайте клієнту стабільне призначення

Клієнту не потрібно, щоб хост бази даних носив адресу з пулу. Маршрутизована схема працює, коли сервер слухає на своїй стабільній приватній адресі, а VPN-шлюз пересилає трафік клієнта до нього і повертає відповідь.

Test-NetConnection -ComputerName 10.80.0.15 -Port 1433
tracert -d 10.80.0.15

Якщо клієнт досягає 10.80.0.15, шлях доведено і базі даних залишається лише авторизувати цього клієнта. Якщо ні, виправте маршрутизацію і DNS, перш ніж знову торкатися слухача, бо проблема прив'язування на сервері ніколи не була причиною, чому клієнт не може його знайти. Додавання фальшивої адреси з пулу на сервер або другого шлюзу за замовчуванням, щоб догодити слухачу, створює нову мережеву проблему поверх старої. Тримайте адресацію сервера статичною і дозвольте тунелю доставляти до нього клієнтів.

Перевірте кінцеву точку, яку використав клієнт

Завершіть перевіркою на рівні застосунку, а не тестом порту. Підключіться з клієнта обліковим записом, який використовує застосунок, і прочитайте відомості про з'єднання на боці сервера, де видно локальну адресу, на яку потрапив ваш сеанс.

sqlcmd -S tcp:10.80.0.15,1433 -Q "SELECT local_net_address, local_tcp_port FROM sys.dm_exec_connections WHERE session_id = @@SPID"

Порівняйте цю адресу з налаштованим слухачем. Розбіжність означає другий слухач або ім'я, що розв'язується в неочікуваному місці, і те й те варто знати до того, як наступне перезавантаження перевірить ваше виправлення за вас. Потім перезавантажте хост без користувача, що ввійшов, і підтвердьте, що прив'язування вдається. Цей єдиний тест — різниця між полагодженим слухачем і обхідним рішенням, яке зазнає невдачі наступної ночі оновлень.

Схожі статті