Која 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 датотеке, материјал статичког кључа и комплетни клијентски пакети не припадају у тикет; имена опција и облик ланца обично су довољни за други пар очију.

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