Распрацоўнікі ўсё шукаюць месца, дзе радок злучэння, 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 або лагін кожны цярніць няўдачу з розным паведамленнем.

Запішыце этап у тыкет. Інакш наступны чалавек паўторыць той самы пошук радка злучэння, з якога ўсё пачалося.

Падобныя артыкулы