OpenVPN 3 Linux: પાછા જતાં પહેલાં D-Bus ભૂલ વાંચો
પાંચ સેવાઓ, એક ફ્રન્ટએન્ડ. D-Bus ભૂલને જે ઘટકે નકાર્યું તેની સાથે જોડો, સત્ર છે કે નહીં તે તપાસો, પછી તે જ સીમા પર સુધારો કરો.
OpenVPN 3 Linuxની નિષ્ફળતાઓ અજાણ્યા નામ સાથે D-Bus પદ્ધતિ ભૂલ તરીકે આવે છે, અને લાલચ એ છે કે પેકેજની આવૃત્તિ નીચે કરવી અને આશા રાખવી. ક્લાયન્ટ એક પ્રોગ્રામ નથી: કમાંડ-લાઇન ફ્રન્ટએન્ડ બસ દ્વારા એ સેવાઓ સાથે વાત કરે છે જે પ્રોફાઇલ, સત્રો, VPN એન્જિન અને વિશેષાધિકાર પ્રાપ્ત નેટવર્ક ફેરફારોના માલિક છે. આ પાંચમાંથી કોણ નિષ્ફળ કૉલનું માલિક છે તે નક્કી કરવું એ નિદાનનો સૌથી મોટો ભાગ છે અને પાછા જવાને બદલે એક કમાંડનો ખર્ચ છે. આગળ એ જ નિર્ણય છે, જે ક્રમમાં નિષ્ફળતાઓ સામાન્ય રીતે દેખાય છે.
એક કમાંડ પાછળ પાંચ માલિક
પાંચ પ્રક્રિયાઓ મહત્ત્વની છે, અને દરેકનું પોતાનું બસ નામ છે: તમારો કમાંડ સ્વીકારતું ફ્રન્ટએન્ડ, પ્રોફાઇલ અને તેમની પ્રવેશ નીતિ રાખતું કન્ફિગરેશન મેનેજર, સત્રનું આયુષ્ય ધરાવતું સત્ર મેનેજર, OpenVPN 3 Core Engine મારફતે જોડાણ ચલાવતું બેકએન્ડ, અને ઇન્ટરફેસ, માર્ગો તથા DNS સેટિંગ્સ સ્થાપિત કરતી નેટવર્ક કન્ફિગરેશન સેવા. તેથી કન્ફિગરેશન ઑબ્જેક્ટનું નામ લેતી ભૂલ બેકએન્ડની ભૂલ નથી, અને શરૂ ન થતું બેકએન્ડ પ્રમાણીકરણની નિષ્ફળતા નથી. સંદેશને એ પંક્તિઓમાંથી એકમાં મૂકવું કોઈપણ ફેરફાર પહેલાં થવું જોઈએ, કારણ કે દરેક આગળનું પગલું કઈ પંક્તિ સાચી છે તેના પર આધારિત છે. પંક્તિનો અંદાજ લગાવવો એ માર્ગ છે જેના પર નાનું સુધારણ પેકેજો સાથે બપોરભરનું કામ બની જાય છે.
બીજું કંઈ પૂછતાં પહેલાં સિસ્ટમ બસને પૂછો કે કઈ સેવાઓ હાજર છે, પછી ખાતરી કરો કે સ્થાપિત ભાગો એક આવૃત્તિ પર સહમત છે. OpenVPN 3 Linux એ સેવાઓને સિસ્ટમ યુનિટ તરીકે નોંધે છે, તેથી પૂછવાની બસ સિસ્ટમ બસ છે, આવૃત્તિની પૃચ્છા માટે વહીવટી સત્તા જરૂરી છે, અને --user સાથે બનાવેલી યાદી તમારા લૉગિન સત્રને વાંચે છે, જ્યાં યુનિટ ક્યારેય દેખાતા નથી. સેવાઓ માંગ પ્રમાણે સક્રિય થાય છે અને કેટલીક નિષ્ક્રિય હોય ત્યારે બંધ થાય છે, તેથી તમારી પહેલી વિનંતી પહેલાં ગેરહાજર સેવાને હજી કશા વિશે પૂછાયું જ નથી. નીચેનાં ત્રણ કમાંડ VPN સત્ર ન ખોલતાં હાજરી, આવૃત્તિ અને યુનિટની સ્થિતિ જણાવે છે.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'દરેક યાદી ખરેખર શું સાબિત કરે છે
ક્લાયન્ટનાં પોતાનાં દૃશ્યો સૌથી સસ્તો ઉપલબ્ધ પુરાવો છે, અને તેમાંથી દરેક દેખાય છે તેના કરતાં ઓછું સાબિત કરે છે. કન્ફિગરેશન યાદીમાં પ્રોફાઇલ દર્શાવે છે કે પ્રોફાઇલ આયાત થઈ છે અને એ વિશે કંઈ કહેતું નથી કે કોઈ તેની સાથે જોડાઈ શકે છે કે નહીં. સત્ર યાદીમાં સત્ર દર્શાવે છે કે સત્ર ઑબ્જેક્ટ અસ્તિત્વમાં છે અને એ વિશે કંઈ કહેતું નથી કે દૂરસ્થ પ્રમાણીકરણ પૂરું થયું છે કે નહીં.
openvpn3 configs-list
openvpn3 sessions-listતે આઉટપુટમાં ઑબ્જેક્ટ માર્ગો બસ પર સંચાલિત ઑબ્જેક્ટ દર્શાવે છે, ફાઇલો નહીં, તેથી તેમને સંપાદિત કરી શકાતા નથી, અને પહેલાં નોંધાયેલો માર્ગ તે ક્ષણે જૂનો થઈ જાય છે જ્યારે તે સત્ર ડિસ્કનેક્ટ થાય છે. તમારી નોંધમાંથી એક ફરી વાપરવાથી "no such object" ભૂલો ઊપજે છે જેનો VPN સાથે કોઈ સંબંધ નથી. નીચેનું તબક્કા કોષ્ટક જોડાણના દરેક પગલાએ શું સ્થાપિત કરે છે અને શું ખુલ્લું છોડે છે તે અલગ કરે છે, અને પાછા જવાનો નિર્ણય બરાબર એ જ ફરક પર ટકેલો છે. તમારા પુરાવા સાથે મેળ ખાતી પંક્તિ વાંચો, પછી ભૂલનું લખાણ ફરી વાંચો.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
જોડાણ કૉલ સુરંગ અસ્તિત્વમાં આવ્યા પહેલાં પાછો ફરે છે
જોડાણ કૉલ તમને દેખરેખ માટે સત્ર આપે છે અને પાછો ફરે છે, તેથી દેખીતી રીતે સફળ કૉલ પછી મૌન એ સામાન્ય મધ્યવર્તી સ્થિતિ છે, વિરોધાભાસ નથી. ફ્રન્ટએન્ડે તો પણ સ્થિતિના ફેરફારોને અનુસરવા પડે છે અને દરેક ક્રિયાપ્રતિક્રિયા વિનંતીનો જવાબ આપવો પડે છે. જે પ્રોફાઇલને ઓળખપત્ર જોઈએ છે અને જવાબ મળતો નથી, તે એવી સ્થિતિમાં રાહ જુએ છે જે અટકી ગયેલા બેકએન્ડ જેવી બરાબર દેખાય છે. એ રાહ જોવાની સ્થિતિ ઓળખાવી જોઈએ, કારણ કે તે લોકોને ખોટા ઘટક તરફ મોકલે છે.
જ્યારે પ્રયાસ ચાલુ હોય, તે પ્રોફાઇલ માટે સત્ર યાદી અને ફ્રન્ટએન્ડનો પોતાનો લૉગ જુઓ. જે સત્ર પોતાની શરૂઆતની સ્થિતિ ક્યારેય છોડતું નથી તે અટકેલા ઘટકનું નામ લે છે, અને લૉગ સામાન્ય રીતે પહેલી જ પંક્તિઓમાં તેનું નામ લે છે. પ્રોફાઇલનું નામ નજીક રાખો, કારણ કે લૉગ કમાંડ સત્ર માર્ગ નહીં પણ પ્રોફાઇલ લે છે, જે માર્ગ ફરી વાપરવાને બદલે યાદી ફરી વાંચવાનું બીજું કારણ છે.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6સત્ર ન ખોલતાં એક ઘટકનો લૉગ વાંચવો
જ્યારે ફ્રન્ટએન્ડ કંઈ ઉપયોગી જણાવતું નથી, ત્યારે નવું જોડાણ શરૂ કરવાને બદલે જે ઘટકે નિષ્ફળતા લૉગ કરી તેની પાસે જાઓ. ગોઠવેલા systemd-journald લૉગર સાથે, વ્યવસ્થાપકનું મર્યાદિત જર્નલ દૃશ્ય એક ઘટકની ઘટનાઓ વાંચે છે, બસ નીતિને સ્પર્શ કર્યા વિના અને સત્ર ન ખોલતાં, અને આ મહત્ત્વનું છે કારણ કે જે નિદાન માપવામાં આવતી સિસ્ટમને જ બદલી નાખે છે તે ઘણું ઓછું સાબિત કરે છે. યુનિટ પ્રમાણે ગાળો, syslog ટૅગ પ્રમાણે નહીં: અલગ અલગ સેવા યુનિટ સહિયારી ઓળખની બાંયધરી આપતા નથી, તેથી ટૅગની પૃચ્છા ખાલી પૃષ્ઠ પાછું આપી શકે છે જ્યારે યુનિટે પોતે નિષ્ફળતા નોંધી હોય.
કોઈની મદદ માંગતાં પહેલાં ચાર ક્ષેત્રો લખો: ભૂલનું પૂરું નામ, સંબંધિત સેવા અને ઑબ્જેક્ટ, સમયની મહોર, અને સ્થાપિત પેકેજોની આવૃત્તિઓ. આ જ તે છે જે જાળવણીકર્તાને જોઈએ છે, અને આમાંથી કોઈ પણ માટે પ્રોફાઇલ કે ઓળખપત્ર ટિકિટમાં ચીપકાવવાની જરૂર નથી. ભૂલ શાંત કરવા બસ પ્રવેશ નીતિ પહોળી કરવી એ નિદાન નથી, તે એ સીમા ભૂંસી નાખે છે જે તમારા વતી ઘટકનું નામ લેતી હતી. પ્રોફાઇલની ખાનગી સામગ્રી વહેંચાયેલા અહેવાલોની બહાર રહે છે, જે કારણે ઓળખપત્રો બહાર રહે છે તે જ કારણે.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>જે સીમાએ નકાર્યું તેનું સુધારણ
નકશાની દરેક પંક્તિનું પોતાનું સુધારણ છે, અને પંક્તિઓ એકબીજાની જગ્યા લેતી નથી. પ્રોફાઇલ પર નકારેલી ક્રિયા નીતિ અને માલિકીનો પ્રશ્ન છે, જ્યારે સક્રિય ન થતું બેકએન્ડ સેવાઓ અને પેકેજિંગનો પ્રશ્ન છે. પ્રમાણીકરણ નકારતું સર્વર આમાંથી કોઈ નથી, તેથી વારંવાર પાસવર્ડ બદલવાથી સ્થાનિક સક્રિયકરણની સમસ્યા સુધારી શકાતી નથી. ખોટું સુધારણ પસંદ કરવું એ માર્ગ છે જેના પર નીતિની સમસ્યા ફરીથી સ્થાપન બની જાય છે.
પેકેજ બદલાયા પછી જૂની બાઇનરી તેની જગ્યાએ કૉપિ કરવાને બદલે સુસંગત અને સમર્થિત સ્થાપન ચકાસો. નિયંત્રિત પાછા જવું એ પુષ્ટ થયેલા રિગ્રેશનનો કાયદેસર જવાબ છે, જો પેકેજો સુસંગત રહે અને સમર્થિત જાળવણી તરફ પાછા જવાનો માર્ગ અસ્તિત્વમાં હોય. તે માર્ગ સેવા શરૂ થવાનું બંધ કરે તે પહેલાં સ્થાપિત કરો, પછી નહીં.
બીજું પ્લેટફોર્મ એ જ મૂળ VPN લાઇબ્રેરી વહેંચી શકે છે Linuxની બસ સેવાઓ વહેંચ્યા વિના, તેથી Windows પર મળતી જેવી નિષ્ફળતા આ વિશે કંઈ કહેતી નથી. D-Busની ઝલક કન્ફિગરેશન અને સત્રો માટે ખુલ્લા કરાયેલા ઑબ્જેક્ટ માર્ગોનું દસ્તાવેજીકરણ કરે છે, અને આ નિદાન જે સ્થાપત્ય પર ટકેલું છે તે બરાબર એ જ ભાગ છે. એક વાર વાંચો, અને આગલી ભૂલ પહેલેથી તેની સાથે જોડાયેલા ઘટક સાથે આવશે.