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