Кой екземпляр на OpenVPN всъщност използва вашия профил на PiVPN?

PiVPN записва сървърна конфигурация и клиентски профил, след което излиза; той никога не става процесът, който пренася трафика ви. Затова неуспешен ръкостиск, клиент, който се свързва с грешна крайна точка, или услуга, която след рестарт се връща сгрешена, не могат да се обяснят от менютата на инсталатора. Тези симптоми принадлежат на демона OpenVPN, който работи в момента, на конфигурацията, която този демон действително е заредил, и на журнала, към който е насочен. Четири команди само за четене обикновено решават въпроса и нито една от тях не променя сертификатите или ключовете ви.

Помощникът и демонът са различни обекти

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

На systemd хост започнете от активния unit, а не от списъка на папката. Името зависи от пакетирането: образите на Debian и Raspberry Pi OS обикновено предоставят шаблонен екземпляр като openvpn-server@server, докато по-старите инсталации използват openvpn@server. Попитайте мениджъра кой работи, вместо да гадаете по име на файл.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Прочетете ExecStart= в този изход. Той посочва изпълнимия файл и опциите, които мениджърът действително стартира, включително всеки --config път; конфигурационен файл, който лежи наблизо и към който не сочи нито една команда, не е част от работещия тунел.

Проследете конфигурационната верига, която демонът е разрешил

OpenVPN не сканира папка за настройки. Той чете файла, подаден с --config, следва всякакви config директиви вътре в него и после прилага опциите от командния ред. Ръководството 2.6 описва тази подредба и това има значение, когато два файла не са съгласни за порта, устройството или шифъра.

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Файл .ovpn в домашна папка е клиентски артефакт. Сървърният демон никога не го чете, така че редактирането на този файл, за да поправите сървърен провал на ръкостискане, не постига нищо.

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

Съпоставете журнала с процеса, а не с грешката, която помните

Две дестинации за журнал са обичайни и само една от тях е системният журнал. С log-append демонът пише в този файл и системният журнал пази малко освен редовете при стартиране. Без него journalctl е източникът на събития.

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

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

Преизграждането на тунела не е диагностична стъпка

Изкушаващият пряк път е да вдигнете втори, по-прост тунел: статичен ключ, без сертификати, без допълнително удостоверяване. Той често ще се свърже и доказва само, че два хоста могат да прекарат UDP или TCP помежду си. Не казва нищо за това защо внедряването със сертификати се проваля и тихомълком заменя модела за сигурност, който сте били помолени да запазите.

Същото важи за изключването на tls-auth или tls-crypt, разхлабването на verify-x509-name, или премахването на втори фактор, за да получите зелен статус. Тунел, който се свързва, защото проверката е премахната, е друга система, а не поправена.

Направете една ограничена промяна на слоя, който журналът посочи, рестартирайте същия unit и повторете единствения опит за връзка. Това пази сравнението честно и оставя промяна, която можете да върнете.

Какво да предадете на следващия човек

Запишете четири факта, докато още ги имате: версията на OpenVPN от openvpn --version, unit-а, който е активен, конфигурационната верига с включванията ѝ и прозореца на журнала, покриващ един опит. Тези четири превръщат смътна оплакване в възпроизводим случай.

Редактирайте преди да споделяте. Частни ключове, auth-user-pass файлове, материал за статичен ключ и цели клиентски пакети не принадлежат в тикет; имената на опциите и формата на веригата обикновено са достатъчни за втори чифт очи.

Ако веригата е непокътната и журналът все още сочи към мрежата, следващата стъпка е пътят между клиента и сървъра, а не още една инсталация. Това е единствената част от историята, която помощникът никога не е притежавал.