OpenVPN neieslēdzas: lasiet pirmo rindu, ne konfigurāciju

VPN, kas mirst pirmajā sekundē, ir cits dzīvnieks nekā tas, kas pieslēdzas un pēc tam neizdodas, un ierastā kļūda ir tos uzskatīt par vienu un to pašu. Šeit nav ne handshake, ne sertifikātu apmaiņas, ne maršruta, ko apskatīt. Viena rinda žurnālā izlemj, kura no vairākiem nesaistītiem labojumiem ir spēkā, un tās izlaišana maksā pusi dienas, rediģējot konfigurāciju, kas nekad netika nolasīta. Vispirms izlasiet šo rindu.

Trīs tikai lasīšanas komandas aizvedīs jūs turp: vispirms journalctl -u openvpn@server -b --no-pager, tad systemctl status openvpn@server, un ss -lunp UDP klausītājiem un to īpašniekiem.

Pirmā rinda izvēlas zaru

Porta konflikts un trūkstošs binārais fails abi nogalina palaišanu sekundes laikā, un tie atstāj atšķirīgas pirmās rindas. Ziņa, ka adrese jau tiek izmantota, nosauc portu; trūkstošs izpildfails nosauc ceļu, kas vairs neeksistē; neizdevies nosacījums vai trūkstošs konfigurācijas fails nosauc failu. Šie trīs ved pie atšķirīgiem labojumiem, un nevienu no tiem neuzlabo klienta pārinstalēšana. Nokopējiet pirmo kļūdu savos pierakstos, pirms palaižat ko citu.

Pievērsiet uzmanību atkārtošanas cilpai, kas slēpj sākotnējo rindu. Vienība ar restartēšanas politiku var aprakt pirmo kļūdu zem desmitiem identisku, tāpēc journalctl -b, filtrēts pēc vienības un lasīts no augšas, pārspēj asti.

Kas vēl tur 1194 portu

Vainīgais parasti nav otrs serveris, ko kāds apzināti konfigurējis. Gaidiet ar roku palaistu klientu, kas vēl dzīvs citā terminālī, otru profilu, kas nejauši izvēlējās to pašu portu, vai piegādātāja pakotni, kuras pašas tunelis tur 1194. Ligzdas īpašnieks parādās ss -lunp; nododiet šo PID komandai systemctl status, lai uzzinātu, vai atbildīga ir kāda vienība. Izslēdziet to pa tās pašas vadības ceļu, nevis ar signālu.

Signāls vienības pārvaldītam procesam parasti izraisa restartēšanu, un tā pati kļūda pēc brīža parādās no jauna kā jauna problēma. Izmantojiet systemctl stop vienībai, pašas pakotnes pakalpojuma komandu piegādātāja instalācijai un signālu tikai tam, ko paši palaidāt ar roku tajā shell.

Pēc noņemšanas palikušās vienības

Noņemšana dzēš bināros failus; ar roku rakstītie vienību faili, parasti zem /etc/systemd/system, to pārdzīvo. Tad Systemd atkal mēģina vienību, kas norāda uz ceļu, kurš vairs neeksistē, un ziņa attiecas uz to trūkstošo failu, nevis uz vakardienas noņemšanu. systemctl status rāda vienības fragmenta ceļu augšpusē, tāpēc pārbaudiet to ar dpkg -S, pirms kaut ko dzēšat. Kad bārenis pazūd, systemctl daemon-reload un systemctl reset-failed notīra stāvokli; citādi katrs vēlākais statusa pārbaudījums to manto.

Kad which openvpn atbild ar kaut ko zem /usr/local, izmantotais binārais fails nāca no piegādātāja instalētāja, nevis no apt. Šāds instalētājs parasti atnes savu klausītāju, savu palaišanas ierakstu un savu konfigurācijas direktoriju, tāpēc redzamās komandas noņemšana atstāj ligzdu aizņemtu.

Atinstalējiet to tā, kā dokumentē piegādātājs, pārliecinieties, ka ports ir brīvs, ar ss -lunp, un pievienojiet distribūcijas klientu tikai tad, ja tas jums vajadzīgs.

Sakārtojiet stāvokli pirms atkārtota mēģinājuma

Notīriet neizdevušos stāvokli, pirms izdarāt no tā secinājumus: systemctl reset-failed noņem skaitītājus, un systemctl status tad ziņo par vienības pašreizējo stāvokli, nevis tās vēsturi. Palaidiet to vienreiz un lasiet tā palaišanas žurnālu, nevis mašīnas apkopoto stāvokli. Vienība, kas ziņo par aktivitāti, kamēr tunelis neko nepārvadā, ir atsevišķa problēma un daudz izplatītāka. Abas saplūst kļūdu ziņojumos, jo abas beidzas ar lietotāja teikto, ka VPN nestrādā.

Pierakstiet, kuru zaru izvēlējāties: porta konflikts, trūkstošs binārais fails, trūkstoša konfigurācija. Nākamreiz atpazīt būs ātrāk.