OpenVPN 3 Linux: lexo një gabim D-Bus përpara se të kthesh versionin

Dështimet e OpenVPN 3 Linux vijnë si gabim i metodës D-Bus me një emër të panjohur të bashkangjitur, dhe tundimi është të ulësh versionin e një pakete dhe të shpresosh. Klienti nuk është një program i vetëm: një frontend i rreshtit të komandës flet përmes autobusit me shërbime që zotërojnë profilet, sesionet, motorin VPN dhe ndryshimet e privilegjuara të rrjetit. Të vendosësh se cili prej atyre pesë zotëron thirrjen që dështon është pjesa më e madhe e diagnozës, dhe kushton një komandë në vend të një kthimi versioni. Ajo që vijon është ai vendim, në rendin në të cilin dështimet zakonisht shfaqen.

Pesë pronarë pas një komande

Pesë procese kanë rëndësi, dhe secili ka emrin e vet të autobusit: frontend-i që pranon komandën tënde, menaxheri i konfigurimit që ruan profilet dhe politikën e tyre të aksesit, menaxheri i sesioneve që zotëron jetëgjatësinë e sesionit, backend-i që drejton lidhjen përmes OpenVPN 3 Core Engine, dhe shërbimi i konfigurimit të rrjetit që instalon ndërfaqen, rrugët dhe cilësimet e DNS. Një gabim që emërton një objekt konfigurimi pra nuk është gabim i backend-it, dhe një backend që nuk niset nuk është dështim autentikimi. Klasifikimi i mesazhit në një nga ato rreshta duhet të ndodhë përpara se të ndryshohet çdo gjë, sepse çdo hap i mëvonshëm varet nga ajo se cili rresht është i vërtetë. Hamendësimi i rreshtit është mënyra se si një rregullim i shkurtër bëhet një pasdite me paketa.

Pyet autobusin e sistemit se cilat shërbime janë të pranishme përpara se të pyesësh çdo gjë tjetër, pastaj konfirmo që pjesët e instaluara bien dakord për një version. OpenVPN 3 Linux i regjistron ato shërbime si njësi të sistemit, kështu që autobusi për t'u pyetur është ai i sistemit, kërkesa për version kërkon autoritet administrativ, dhe një listim i bërë me --user lexon sesionin tënd të hyrjes, ku njësitë nuk shfaqen kurrë. Shërbimet aktivizohen sipas kërkesës dhe disa dalin kur janë boshe, kështu që një shërbim që mungon përpara kërkesës tënde të parë thjesht nuk është pyetur ende për asgjë. Tre komandat më poshtë përgjigjen për praninë, versionin dhe gjendjen e njësisë pa hapur një sesion VPN.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Çfarë vërteton vërtet secila listë

Pamjet e vetë klientit janë prova më e lirë e disponueshme, dhe secila prej tyre vërteton më pak sesa duket. Një profil në listën e konfigurimit tregon se një profil është importuar dhe asgjë për atë nëse dikush mund të lidhet me të. Një sesion në listën e sesioneve tregon se ekziston një objekt sesioni dhe asgjë për atë nëse autentikimi në distancë përfundoi.

openvpn3 configs-list
openvpn3 sessions-list

Rrugët e objekteve në ato dalje identifikojnë objekte të menaxhuara në autobus dhe jo skedarë, kështu që nuk mund të redaktohen, dhe një rrugë e regjistruar më herët vjetrohet në momentin kur ai sesion shkëputet. Ripërdorimi i njërës prej shënimeve të tua prodhon gabime "no such object" që nuk kanë asgjë të përbashkët me VPN-në. Tabela e fazave më poshtë ndan atë që ndërton çdo hap i një lidhjeje nga ajo që lë të hapur, dhe pikërisht në atë dallim mbështetet një vendim kthimi versioni. Lexo rreshtin që përputhet me provën tënde, pastaj lexo përsëri tekstin e gabimit.

Thirrja e lidhjes kthehet përpara se tuneli të ekzistojë

Thirrja e lidhjes të jep një sesion për të ndjekur dhe kthehet, prandaj një thirrje në dukje e suksesshme e ndjekur nga heshtja është një gjendje e ndërmjetme normale dhe jo një kundërshtim. Frontend-i duhet të vazhdojë të ndjekë ndryshimet e gjendjes dhe t'u përgjigjet çdo kërkese për ndërveprim. Një profil që ka nevojë për një kredencial dhe nuk merr përgjigje pret në një gjendje që duket saktësisht si një backend i ngecur. Ajo gjendje pritjeje meriton njohje, sepse i dërgon njerëzit te komponenti i gabuar.

Ndërsa një provë është në vazhdim, ndiq listën e sesioneve dhe regjistrin e vetë frontend-it për atë profil. Një sesion që nuk largohet kurrë nga gjendja e tij fillestare emërton komponentin që u ndal, dhe regjistri zakonisht e emërton atë në rreshtat e parë. Mbaj emrin e profilit pranë, sepse komanda e regjistrit merr një profil dhe jo një rrugë sesioni, që është edhe një arsye për të lexuar përsëri listën në vend që të ripërdorësh një rrugë.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Leximi i regjistrit të një komponenti pa hapur një sesion

Kur frontend-i nuk raporton asgjë të dobishme, shko te komponenti që regjistroi dështimin në vend që të nisësh një lidhje tjetër. Me një regjistrues systemd-journald të konfiguruar, pamja e kufizuar e regjistrit e administratorit lexon ngjarjet e një komponenti pa prekur politikën e autobusit ose pa hapur një sesion, gjë që ka rëndësi sepse një diagnozë që ndryshon sistemin që mat provon shumë pak. Filtro sipas njësie dhe jo sipas etiketës syslog: njësitë individuale të shërbimit nuk garantojnë një identifikues të përbashkët, kështu që një kërkesë sipas etikete mund të kthejë një faqe bosh ndërsa vetë njësia regjistroi dështimin.

Shkruaj katër fusha përpara se t'i kërkosh ndokujt ndihmë: emrin e plotë të gabimit, shërbimin dhe objektin e përfshirë, vulën kohore dhe versionet e paketave të instaluara. Këto janë ato që i nevojiten një mirëmbajtësi, dhe asnjëra prej tyre nuk kërkon ngjitjen e një profili ose kredenciali në një biletë. Zgjerimi i politikës së aksesit të autobusit për ta heshtur gabimin nuk është diagnozë, fshin kufirin që po e emërtonte komponentin për ty. Përmbajtja private e profileve mbetet jashtë raporteve të përbashkëta për të njëjtën arsye si kredencialet.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Korrigjimi i kufirit që refuzoi

Çdo rresht i hartës ka korrigjimin e vet, dhe rreshtat nuk zëvendësojnë njëri-tjetrin. Një operacion i refuzuar në një profil është një pyetje për politikën dhe pronësinë, ndërsa një backend që nuk aktivizohet është një pyetje për shërbimet dhe paketimin. Një server që refuzon autentikimin nuk është asnjëri, kështu që ndryshimet e përsëritura të fjalëkalimit nuk mund të rregullojnë një problem lokal aktivizimi. Zgjedhja e korrigjimit të gabuar është mënyra se si një problem politike bëhet riinstalim.

Pas një ndryshimi paketash, verifiko një instalim koherent dhe të mbështetur në vend që të kopjosh një binar të vjetër në vendin e tij. Një kthim i kontrolluar versioni është një përgjigje legjitime ndaj një regresioni të konfirmuar, me kusht që paketat të mbeten të përputhshme dhe të ekzistojë një rrugë kthimi drejt mirëmbajtjes së mbështetur. Krijo atë rrugë përpara se shërbimi të ndalojë së nisuri, jo pas.

Një platformë tjetër mund të ndajë të njëjtën bibliotekë bazë VPN pa ndarë shërbimet e autobusit të Linux-it, kështu që një dështim i ngjashëm në Windows nuk thotë asgjë për këtë. Pamja e përgjithshme e D-Bus dokumenton rrugët e objekteve të ekspozuara për konfigurime dhe sesione, dhe kjo është pjesa e arkitekturës nga e cila varet kjo diagnozë. Lexoje një herë, dhe gabimi tjetër do të vijë me një komponent të bashkangjitur tashmë.