OpenVPN двигател или Tunnelblick: кой притежава VPN сесията на Mac?

Homebrew инсталира програма OpenVPN; Tunnelblick инсталира мениджър, който стартира един или повече двигатели. Това са различни слоеве и полезният въпрос не е дали ви харесва да използвате терминал. А кой притежава конфигурацията, промените в DNS, подканата за идентификационни данни и почистването при края на сесията. Единният собственик на тези слоеве е това, което прави настройката предвидима.

Минете през петте проверки по-долу по ред. Първата, при която има двама собственици, е тази, която създава странните полусвързани състояния, които хората обвиняват самия OpenVPN. Всяка проверка посочва доказателството, което я решава.

Проверка първа: кой изпълним файл на OpenVPN реално работи

Изпълнете pgrep -fl openvpn, докато сте свързани, и прочетете целия команден ред. Първият път е двигателят, който реално работи. При Apple Silicon инсталацията от Homebrew обикновено е под /opt/homebrew, докато Intel Mac използват /usr/local, а Tunnelblick стартира двигател от собствения си пакет на приложението.

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

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

Проверка втора: кой променя DNS и маршрутите

Двигателят може да изпълнява собствените директиви up и down на OpenVPN, но мениджърът може да притежава същия жизнен цикъл. Настройките за сървър за имена в Tunnelblick управляват стандартните му скриптове за свързване и прекъсване и когато тази интеграция е включена, конкуриращите директиви в профила могат да бъдат игнорирани.

Това има значение, защото DNS е мястото, където работещ тунел най-често изглежда счупен. Проверете scutil --dns, докато сте свързани, отбележете кой резолвер е първи и потвърдете, че се връща след прекъсване. Ако профилът очаква да зададе DNS сам, докато мениджърът също го управлява, един от двамата ще загуби.

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

Проверка трета: откъде идват идентификационните данни

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

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

Проверка четвърта: кой стартира, наблюдава и спира процеса

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

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

Който и собственик да изберете, определете какво се случва при заспиване, смяна на мрежата и изход. Мениджърът обикновено се справя с тези събития; голият процес обикновено не и остарелият маршрут или резолвер лесно се разчита като повреда на сървъра.

Проверка пета: как се проверява предаването

Тествайте новия собственик с изключен стар, после тествайте стария отново, ако планирате да го запазите. Частен ресурс, който отговаря при един работен процес и не отговаря при другия, е доказателство за липсващата интеграция, а не за сървъра.

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

За предаване към Tunnelblick изберете двигателя за конфигурацията, включете интеграцията с DNS, която възнамерявате, и премахнете директивите в профила, които ѝ противоречат. След това повторете същите три проверки. Връзка, която работи, но оставя резолвера променен, е неуспешно предаване, дори тунелът да е вдигнат.

Опаковането не решава съвместимостта със сървъра. Проверете собствените изисквания на услугата към клиента и изберете само двигателя само когато възнамерявате да осигурите управлението му.