Која OpenVPN инстанца всушност го користи твојот PiVPN профил?

PiVPN пишува серверска конфигурација и клиентски профил, потоа излегува; никогаш не станува процесот што го носи твојот сообраќај. Затоа неуспешното ракување, клиент што бира погрешен крај или услуга што се враќа погрешно по рестарт не можат да се објаснат од менијата на инсталаторот. Овие симптоми и припаѓаат на оној OpenVPN демон што работи сега, на конфигурацијата што тој демон навистина ја вчита и на дневникот кон кој беше насочен. Четири команди само за читање обично го решаваат тоа, и ниту една не ги менува твоите сертификати или клучеви.

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

Збунетоста е лесно да се објасни: една папка го држи фајлот што го создаде помошникот, фајлот што го чита демонот, а понекогаш и застарена копија од двете. Помошникот е скрипта за подготвување. Таа инсталира пакети, пишува единечни датотеки и печати клиентски профил, а потоа нејзината работа завршува. Она што останува е запис во менаџерот на услуги и командна линија.

На systemd домаќин започни од активната единица, а не од списокот на папката. Името зависи од пакувањето: 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 вовлекува втора датотека чии опции се обработуваат на тоа место, па подоцнежна директива со една вредност може да го надвладее она што главната датотека навидум го вели. Ако видливата датотека изгледа точно, а демонот сѐ уште се однесува поинаку, прочитај ја вклучената датотека пред да промениш нешто.

Спој го дневникот со процесот, не со грешката што ја паметиш

Две одредишта за дневник се вообичаени, и само едно од нив е journal. Со log-append поставено, демонот пишува во таа датотека, а journal чува малку освен линиите за стартување. Без тоа journalctl е изворот на настани.

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

Поврзи еден обид за поврзување со еден временски прозорец. Запиши го крајот на клиентот, потоа читај серверски настани од истите секунди. TLS ракување што никогаш не стигнува до размената на сертификати укажува на достапност или несовпаѓање на протоколот, додека одбивањето автентикација доаѓа откако параметрите на тунелот веќе се договорени.

Стариот запис во дневникот не докажува ништо за профил што го симнавте пред пет минути. Генерирај ја клиентската датотека повторно, поврзи се еднаш и читај само линиите што се појавија за време на тој обид.

Запиши го првиот конкретен неуспех, а не последниот општ. Грешка при врзување, неодговорена надворешна размена, одбивање сертификат и одбивање сметка секој те носи на различен слој, а тајмаутот на крајот често го сокрива корисниот настан над него.

Повторното градење на тунелот не е дијагностички чекор

Примамливиот кратен пат е да се подигне втор, поедноставен тунел: статичен клуч, без сертификати, без дополнителна автентикација. Тој често ќе се поврзе, и докажува само дека два домаќини можат да пренесат UDP или TCP меѓу себе. Не кажува ништо за тоа зошто распоредувањето автентикувано со сертификати не успева, и тивко го заменува безбедносниот модел што требаше да го задржиш.

Истото важи за исклучувањето на tls-auth или tls-crypt, олабавувањето на verify-x509-name, или отфрлањето втор фактор за зелен статус. Тунел што се поврзува затоа што проверката е отстранета е друг систем, а не поправен.

Направи една ограничена промена во слојот што го именуваше дневникот, рестартирај ја истата единица и повтори го единствениот обид за поврзување. Тоа го одржува споредувањето чесно и остава промена што можеш да ја вратиш.

Што да му предадеш на следниот човек

Запиши четири факти додека сѐ уште ги имаш: верзијата на OpenVPN од openvpn --version, активната единица, конфигурацискиот ланец со неговите вклучувања и прозорецот на дневникот што покрива еден обид. Тие четири нејасна жалба ја претвораат во случај што може да се репродуцира.

Редактирај пред да споделиш. Приватните клучеви, auth-user-pass датотеките, статичниот клучен материјал и целосните клиентски пакети не припаѓаат во тикет; имињата на опциите и формата на ланецот обично се доволни за втор пар очи.

Ако ланецот е недопрен и дневникот сѐ уште покажува кон мрежата, следниот чекор е патеката меѓу клиентот и серверот, а не уште една инсталација. Тоа е единствениот дел од приказната што помошникот никогаш не го поседувал.