Ni mfano gani wa OpenVPN unatumia kwa kweli wasifu wako wa PiVPN?

PiVPN huandika usanidi wa seva na wasifu wa mteja, kisha huondoka; kamwe haifanyiki kuwa mchakato unaobeba trafiki yako. Kwa hiyo handshake iliyoshindikana, mteja anayepiga ncha isiyo sahihi, au huduma inayorudi vibaya baada ya kuwasha upya haiwezi kuelezewa kutoka menyu za kisanidi. Dalili hizo ni za daemon ya OpenVPN inayoendesha sasa, usanidi ambao daemon hiyo ilipakia kwa kweli, na logi iliyoelekezwa. Amri nne za kusoma tu kawaida hutatua hili, na hakuna hata moja inayobadilisha vyeti au funguo zako.

Msaidizi na daemon ni vitu tofauti

Kuchanganyikiwa ni rahisi kueleza: saraka moja ina faili ambayo msaidizi aliunda, faili ambayo daemon inasoma, na wakati mwingine nakala ya zamani ya zote mbili. Msaidizi ni script ya maandalizi. Inasakinisha pakiti, inaandika faili za kitengo na kuchapisha wasifu wa mteja, kisha kazi yake inaisha. Kinachobaki ni ingizo katika meneja wa huduma na mstari mmoja wa amri.

Kwenye mwenyeji wa systemd, anza na kitengo kinachoendelea badala ya orodha ya saraka. Jina hutegemea ufungashaji: picha za Debian na Raspberry Pi OS kawaida huonyesha mfano wa kiolezo kama openvpn-server@server, wakati usanidi wa zamani hutumia openvpn@server. Muulize meneja ni kipi kinaendesha badala ya kukisia kutoka jina la faili.

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

Soma ExecStart= katika matokeo hayo. Inataja faili inayotekelezwa na chaguo ambazo meneja huanzisha kwa kweli, ikiwa ni pamoja na njia yoyote ya --config ; faili ya usanidi iliyo karibu na ambayo hakuna amri inayoirejelea si sehemu ya handaki inayoendesha.

Fuatilia mnyororo wa usanidi ambao daemon iliutatua

OpenVPN haichunguzi saraka kutafuta mipangilio. Inasoma faili iliyopitishwa na --config, inafuata config maagizo yoyote ndani yake, kisha inatumia chaguo za mstari wa amri. Mwongozo 2.6 unaeleza mpangilio huo, na hilo ni muhimu wakati faili mbili hazikubaliani kuhusu bandari, kifaa au cipher.

Kwanza toa mwito halisi, kisha angalia maagizo yanayoamua utambulisho na ufikivu. Amri zote mbili ni za kusoma tu na salama kwenye seva inayoendesha, ingawa ya pili inachapisha njia ambazo huenda usizitake katika tiketi ya umma.

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

Faili .ovpn katika saraka ya nyumbani ni bidhaa ya mteja. Daemon ya seva haisomi kamwe, kwa hiyo kuhariri faili hiyo ili kurekebisha hitilafu ya handshake upande wa seva hakufanikishi chochote.

Ujumuishaji ni mtego mwingine. Mstari config unavuta faili ya pili ambayo chaguo zake huchakatwa mahali hapo, kwa hiyo maagizo ya baadaye yenye thamani moja yanaweza kupitiliza kile faili kuu inavyoonekana kusema. Ikiwa faili inayoonekana inaonekana sahihi na daemon bado inafanya tofauti, soma faili iliyojumuishwa kabla ya kubadilisha chochote.

Oanisha logi na mchakato, si na hitilafu unayokumbuka

Maeneo mawili ya logi ni ya kawaida, na moja tu kati yao ni journal. Kwa log-append kuweka, daemon huandika kwenye faili hiyo na journal huhifadhi kidogo zaidi ya mistari ya kuanza. Bila hiyo journalctl ndicho chanzo cha matukio.

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

Unganisha jaribio moja la muunganisho na dirisha moja la muda. Andika ncha ya mteja, kisha soma matukio ya seva kutoka sekunde hizo hizo. Handshake ya TLS ambayo haifiki kamwe kwenye kubadilishana vyeti inaonyesha ufikivu au kutokubaliana kwa itifaki, wakati kukataliwa kwa uthibitishaji huja baada ya vigezo vya handaki kuwa tayari kukubaliwa.

Kumbukumbu ya zamani ya logi haithibitishi chochote kuhusu wasifu uliopakua dakika tano zilizopita. Tengeneza upya faili ya mteja, unganisha mara moja, na soma mistari iliyoonekana wakati wa jaribio hilo pekee.

Andika hitilafu ya kwanza mahususi, si ile ya mwisho ya jumla. Hitilafu ya bind, kubadilishana kwa nje bila jibu, kukataliwa kwa cheti na kukataliwa kwa akaunti kila moja hukupeleka tabaka tofauti, na muda wa mwisho mara nyingi huficha tukio muhimu lililo juu.

Kujenga upya handaki si hatua ya utambuzi

Njia ya mkato inayovutia ni kusimamisha handaki ya pili, rahisi zaidi: ufunguo tuli, hakuna vyeti, hakuna uthibitishaji wa ziada. Mara nyingi itaunganisha, na inathibitisha tu kwamba wenyeji wawili wanaweza kupitisha UDP au TCP kati yao. Haisemi chochote kuhusu kwa nini usambazaji uliothibitishwa kwa vyeti unashindikana, na inabadilisha kimyakimya mtindo wa usalama uliotakiwa kuubakiza.

Vivyo hivyo kwa tls-auth au tls-crypt, kulegeza verify-x509-name, au kuacha kipengele cha pili ili kupata hali ya kijani. Handaki inayounganika kwa sababu uthibitishaji uliondolewa ni mfumo mwingine, si uliorekebishwa.

Fanya badiliko moja lenye mipaka katika tabaka ambalo logi ilitaja, anzisha upya kitengo hicho hicho, na urudie jaribio moja la muunganisho. Hiyo huweka ulinganisho ukiwa waaminifu, na huacha badiliko unaloweza kurudisha.

Nini cha kumkabidhi mtu anayefuata

Andika ukweli manne ukiwa bado unayo: toleo la OpenVPN kutoka openvpn --version, kitengo kinachoendelea, mnyororo wa usanidi pamoja na ujumuishaji wake, na dirisha la logi linaloangazia jaribio moja. Manne hayo hubadilisha malalamiko yasiyoeleweka kuwa kesi inayoweza kuzalishwa tena.

Ficha data nyeti kabla ya kushiriki. Funguo za faragha, auth-user-pass faili, nyenzo za ufunguo tuli na vifurushi kamili vya mteja haviambatani na tiketi; majina ya chaguo na umbo la mnyororo kawaida hutosha kwa jozi ya pili ya macho.

Ikiwa mnyororo haujaharibika na logi bado inaelekeza kwenye mtandao, hatua inayofuata ni njia kati ya mteja na seva, si usakinishaji mwingine. Hiyo ndiyo sehemu moja ya hadithi ambayo msaidizi hakuwahi kuimiliki.