OpenVPN haiwashi: soma mstari wa kwanza, si usanidi

VPN inayokufa katika sekunde ya kwanza ni mnyama tofauti na ile inayounganisha kisha kushindwa, na kosa la kawaida ni kuzichukulia kama kitu kimoja. Hapa hakuna makubaliano, hakuna kubadilishana vyeti na hakuna njia ya kuchunguza. Mstari mmoja katika kumbukumbu huamua ni ukarabati upi kati ya kadhaa usiohusiana, na kuuacha huleta gharama ya alasiri nzima ukihariri usanidi ambao haukusomwa kamwe. Soma mstari huo kwanza.

Unafika hapo kwa amri tatu za kusoma tu: journalctl -u openvpn@server -b --no-pager kwanza, systemctl status openvpn@server pili, na ss -lunp kwa wasikilizaji wa UDP na wamiliki wao.

Mstari wa kwanza huchagua tawi

Mgongano wa mlango na faili ya binary inayokosekana vyote huvunja uanzishaji ndani ya sekunde moja, na huacha mistari ya kwanza tofauti. Ujumbe kuhusu anwani iliyotumika tayari hutaja mlango; faili teke inayokosekana hutaja njia ambayo haipo tena; sharti lililoshindwa au faili ya usanidi isiyopo hutaja faili. Hizo tatu huongoza kwenye ukarabati tofauti, na hakuna hata moja inayoboreshwa kwa kusakinisha upya mteja. Nakili kushindwa kwa kwanza kwenye madokezo yako kabla ya kuendesha kitu kingine.

Jihadhari na mzunguko wa kujaribu tena unaoficha mstari wa asili. Kitengo kilicho na sera ya kuwasha upya kinaweza kufunika kushindwa kwa kwanza chini ya dazeni zinazofanana, kwa hiyo journalctl -b iliyochujwa kwa kitengo na kusomwa kutoka juu ni bora kuliko mkia.

Nani mwingine anashikilia mlango 1194

Mkosaji kwa kawaida si seva ya pili ambayo mtu aliisanidi kwa makusudi. Tegemea mteja aliyewashwa kwa mkono ambaye bado yuko hai kwenye terminal nyingine, profaili ya pili iliyochagua mlango huo huo kwa bahati, au kifurushi cha muuzaji ambacho handaki yake yenyewe inashikilia 1194. Mmiliki wa soketi anaonekana katika ss -lunp; peana PID hiyo kwa systemctl status ili kujua kama kitengo kinahusika. Ishushe kupitia njia yake ya udhibiti, si kwa ishara.

Ishara kwa mchakato unaosimamiwa na kitengo kwa kawaida husababisha kuwasha upya, na kushindwa huko huko hurejea baada ya muda mfupi kikionekana kama tatizo jipya. Tumia systemctl stop kwa kitengo, amri ya huduma ya kifurushi yenyewe kwa usakinishaji wa muuzaji, na ishara kwa kitu ulichokianzisha kwa mkono katika shell hiyo tu.

Vitengo vilivyobaki baada ya kusafisha

Kusafisha hufuta faili za binary; faili za vitengo zilizoandikwa kwa mkono, kwa kawaida chini ya /etc/systemd/system, huokoka. Systemd kisha hujaribu tena kitengo kinachoelekeza kwenye njia ambayo haipo tena, na ujumbe unahusu faili hiyo inayokosekana badala ya uondoaji wa jana. systemctl status huonyesha njia ya kipande cha kitengo karibu na juu, kwa hiyo iangalie kwa dpkg -S kabla ya kufuta chochote. Baada ya yatima kuondolewa, systemctl daemon-reload na systemctl reset-failed husafisha hali; vinginevyo ukaguzi wowote wa hali baadaye hurithi hiyo.

Wakati which openvpn inajibu kwa kitu chini ya /usr/local, faili ya binary inayotumika ilitoka kwa kisakinishi cha muuzaji na si kwa apt. Kisakinishi kama hicho kwa kawaida huleta msikilizaji wake, kiingilio chake cha kuwasha na saraka yake ya usanidi, kwa hiyo kuondoa amri inayoonekana huacha soketi imechukuliwa.

Ondoa kwa njia yoyote ile muuzaji anayeelekeza, hakikisha mlango uko huru kwa ss -lunp, na ongeza mteja wa usambazaji tu ikiwa unamhitaji.

Tulia hali kabla ya kujaribu tena

Safisha hali iliyoshindwa kabla ya kutoa hitimisho kutoka kwake: systemctl reset-failed huondoa vihesabu, na systemctl status kisha huripoti hali ya sasa ya kitengo badala ya historia yake. Iwashe mara moja na soma kumbukumbu ya tukio hilo lenyewe badala ya hali ya jumla ya sanduku. Kitengo kinachoripoti kiko hai wakati handaki haibebi chochote ni tatizo tofauti, na la kawaida zaidi. Mawili hayo huunganishwa katika ripoti za hitilafu kwa sababu yote huishia kwa mtumiaji kusema VPN haifanyi kazi.

Kumbuka tawi ulilochukua: mgongano wa mlango, binary haipo, usanidi haupo. Tukio lijalo litatambulika kwa haraka zaidi.