Не, низът за връзка не може да стартира вашия 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 или влизането се провалят с различно съобщение.

Запишете етапа в тикета. Иначе следващият човек ще повтори същото търсене на низ за връзка, с което започна всичко.