Услугата OpenVPN се проваля на профил, който графичният интерфейс отваря: пет проверки

Два стартера отварят един и същ профил на една машина и само графичният интерфейс се свързва. Файлът е цял и инсталаторът вероятно е наред; различава се контекстът, който всеки стартер дава на openvpn.exe. Работната директория, идентичността на акаунта и атрибутите на файла пътуват заедно с този контекст. Проверете ги в този ред и спрете на първия, който обяснява грешката.

Потвърдете кой стартер се проваля

Започнете с доказване на разделението. Ако графичният интерфейс се свързва, а услугата не, с един и същ път до профила, файлът се чете от някого и въпросът става кой го чете и откъде. Ако и двете се провалят, профилът е повреден и нищо от това не важи. Запишете името на услугата и точния профил, който ѝ е наредено да зареди.

Услуга, насочена към собствената си директория за автоматично стартиране, може да не зарежда файла, който имате отворен в редактор. Сравнете пътя в конфигурацията на услугата с пътя в графичния интерфейс, знак по знак, защото име на папка в края или различна буква на диска е достатъчно да ви отведе по грешния клон.

Къде се разрешават относителните пътища

Профил, който препраща към ca.crt или към помощен скрипт само по име, изисква търсене спрямо мястото, където се намира процесът. Графичният интерфейс стартира в папката с конфигурацията, така че тези имена се разрешават. Услуга, стартирана от мениджъра на услуги, няма такава начална точка и търсенето се проваля, преди да бъде прочетен какъвто и да е сертификат. Затова един и същ профил работи в единия стартер и не работи в другия.

Дайте на обвивката директория, в която да стартира, или направете всяко препращане абсолютно. Възпроизвеждането на контекста на графичния интерфейс в команден ред изглежда така:

openvpn --cd "C:\VPN\profiles\office" --config "C:\VPN\profiles\office\office.ovpn"

Повишаването на подробността на тази команда показва точния път, който е бил опитан. Направете го преди да промените разрешенията, защото липсващ файл и отказано четене изискват различни поправки. Журналът по подразбиране не ги различава. Един допълнителен флаг спестява час гадаене.

Когато идентичността на услугата не може да чете

Услугата работи като системна идентичност, а не като вас. ACL, който дава на вашия потребител пълен контрол и на никой друг, се проваля там, докато работи безупречно в сесията ви. Профил, съхраняван на свързан диск или на удостоверен споделен ресурс, се проваля по същата причина. Потвърдете разрешенията на файла, преди да гледате каквото и да е друго.

Проверката е четене на ефективните разрешения плюс четене, опитано като идентичността на услугата. Изпълнете първата част от повишен команден ред:

icacls "C:\VPN\profiles\office\office.ovpn"

След това опитайте същото четене като идентичността на услугата, например с psexec -s -i от Sysinternals, и наблюдавайте дали файлът се отваря. Ако не, никаква поправка на пътя няма да помогне. Поправете ACL или преместете профила на място, което идентичността на услугата може да чете.

Шифроването на ниво файл е вторият, по-рядък случай. Профил, маркиран с атрибута Encrypting File System, се дешифрира прозрачно за потребителя, който го е шифровал, и остава нечетим за системния акаунт. Затова същият файл се отваря в редактора ви и не се отваря под услугата.

Атрибутът е видим от повишен команден ред и проверката му не отваря профила. Изпълнете двете команди и прочетете изхода:

cipher /s:"C:\VPN\profiles\office"
attrib "C:\VPN\profiles\office\office.ovpn"

Премахването на атрибута прави файла четим, но също така премахва защитата, която той носеше. Ако профилът трябва да остане защитен, поставете тайния материал там, където идентичността на услугата има изрично разрешение, вместо да разчитате на шифроване за отделен потребител. Такава подредба оцелява при смяна на парола и прави достъпа проверим от някой друг, а не от човека, шифровал файла.

Решаване кой притежава тунела

Графичният интерфейс може да поиска парола и да прочете сертификат от хранилището ви за потребителя. Услугата не може нито едното, нито другото, затова профил, който зависи от интерактивна тайна, никога няма да стартира без надзор, колкото и да се поправят пътищата. Това ограничение е проектно решение, а не дефект, който да се заобикаля. Изберете един собственик, преди да промените нещо друго.

Ако тунелът трябва да работи преди вход в системата, дайте на услугата източник на идентификационни данни без надзор и собствено копие на профила. Ако трябва да съществува само докато сте на бюрото, дръжте го в графичния интерфейс и премахнете копието на услугата. Двете наведнъж е конфигурацията, която създава конфликти на адаптери и дублирани маршрути.

Този конфликт обикновено се диагностицира като грешка в конфигурацията, а не като двама собственици, борещи се за един адаптер. Журналът на събитията ще покаже един процес, който не успява да отвори устройството TAP, което изглежда като проблем с разрешенията, а не е. Пребройте собствениците първо.

Какво всъщност стартира обвивката на услугата

Входната точка на услугата е малка обвивка, която чете собствените си запазени параметри и след това стартира openvpn.exe. Когато командният ред в журнала на събитията не съвпада с очакванията ви, тези стойности са нещото, което трябва да се прегледа. Преинсталирането ги връща към стойностите по подразбиране и унищожава доказателствата. Прочетете ги първо.

Стойностите живеят в регистъра под собствения ключ на услугата и sc qc показва пътя до изпълнимия файл, който мениджърът на услуги ще стартира. Сравнете този път със запазената конфигурация на обвивката, преди да редактирате който и да е от двата.

Заместването на обвивката със скрипт, който контролирате, е по-инвазивно, но сгъва ефективния команден ред в един четим файл. Завършете с рестарт, след което четете журнала за профила, докато се появи първият успешен ред за стартиране. Състояние на услугата „работи“ означава само, че обвивката не е излязла, което е вярно и когато дъщерният ѝ процес е умрял веднага.