Ні, рядок підключення не може запустити ваш тунель VPN

Розробники досі шукають місце, де рядок підключення, JDBC URL або запис у tnsnames.ora вибирає VPN. Такого місця немає. Тунель встановлює операційна система або клієнт постачальника, який реєструє віртуальний адаптер, і кожна бібліотека бази даних над ним використовує отриманий шар сокетів. Рядок підключення називає хост, порт і облікові дані, і це весь словник.

Міф: рядок підключення може вибрати тунель

Драйвер відкриває TCP-сокет до хоста й порту. Він не має API для підняття тунелю, не має поля для профілю тунелю і не має способу автентифікуватися на шлюзі VPN.

Тому інструменти поводяться однаково, щойно з'являється маршрут. SSMS, DBeaver, Eclipse Data Tools і звичайний sqlcmd діють так, ніби сервер у локальній мережі, бо з погляду сокета так і є. Віртуальний адаптер зробив підмережу бази даних досяжною, і драйвер ніколи не знає як.

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

Підніміть тунель до запуску драйвера

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

Тримайте нагляд за тунелем поза застосунком. Служба на PHP або Java, яка сама намагається підняти зв'язок, зашиває поведінку одного постачальника в бізнес-код, і кожне перемикання при збої стає випуском застосунку. Наглядач, який володіє тунелем, стежить за ним і перезапускає його, — окреме питання від шляху запиту.

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

Міф: збій автентифікації Windows означає, що маршрут зламано

Автентифікація Windows через VPN часто завершується помилкою, схожою на мережевий збій, хоча маршрут гаразд. Коли обліковий запис належить іншому домену і ноутбук не може до нього приєднатися, запускайте клієнт з явними обліковими даними замість ідентичності сеансу робочого столу.

runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

Ключ /netonly зберігає ці дані лише для віддаленої автентифікації. Підтвердьте, що сервер справді отримав, за допомогою SELECT SUSER_SNAME(), а не довіряючи діалогу підключення. Повідомляють, що збереження облікових даних для адреси сервера в Windows Credential Manager працює для SSMS, але не завжди для служби під іншим обліковим записом, тож перед зміною входу перевірте, яку ідентичність використовує процес.

Затримка перетворює серверний курсор на тайм-аут

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

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

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

Перевірте порт, екземпляр і локальний фільтр

Іменований екземпляр слухає на динамічному порту, тож підтвердьте порт, а не припускайте 1433. В екземплярі за замовчуванням значення можна прочитати з реєстрового значення TcpPort під ключем SuperSocketNetLib цього екземпляра. Для Oracle перевірте, що хост у tnsnames.ora розв'язується, адреса відповідає і порт слухача дозволено; 1521 — поширене значення за замовчуванням, а не гарантія.

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

Запишіть етап у тікет. Інакше наступна людина повторить той самий пошук рядка підключення, з якого все почалося.