OpenVPN-ը չի մեկնարկում առանց սխալի՞ Տեսեք journal-ը

Հրամանը վերադառնում է, ծառայությունը ցուցադրվում է որպես ձախողված, և տերմինալին ոչ մի բացատրության նման բան չի հասնում։ Այդ լռությունը այն ախտանիշն է, որը մարդիկ նկարագրում են որպես «OpenVPN-ը չի մեկնարկում», և այն գրեթե երբեք չի նշանակում, որ ծրագիրը մահացել է առանց որևէ բան ասելու։ Դա նշանակում է, որ հաղորդագրությունը գնացել է մի ալիք, որը դուք չէիք կարդում, կամ որ այն, ինչ գործարկել եք, այն չէր, ինչ կարգավորել եք։ Երկու դեպքն էլ կարելի է ախտորոշել մեկ րոպեից պակաս ժամանակում, հենց որ դադարեք պրոֆիլը համարել կասկածյալ։

Չորս տեղ է կլանում ելքը՝ unit-ի journal-ը, կապը տիրող plugin-ը, թունելի մյուս ծայրը և այլ binary, քան այն, ինչը, ձեր կարծիքով, աշխատում է։ Յուրաքանչյուրն ունի իր ստուգումը։

Լռությունը նշանակում է, որ դուք ճիշտ ալիքին չէիք հետևում

Առաջին պլանում գործարկումը տպում է ձեր տերմինալին։ Unit-ը տպում է journal-ին, և ձախողված unit-ը կարող է դուրս գալ նախքան որևէ բան գրելը, եթե ձախողումը այն բանում է, թե ինչպես այն գործարկվեց, և ոչ թե այն բանում, թե ինչ ասվեց նրան։ Այս տարբերությունը կարևոր է. journal-ում գրառում չլինելը նշանակում է, որ գործընթացը երբեք իսկապես չի աշխատել, մինչդեռ մեկ գրառում և դրանից հետո ելք նշանակում է, որ այն աշխատել է և ինչ-որ բան մերժել։

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Ավելացրեք systemctl show -p Result -p ExecMainStatus openvpn-client@office՝ մաքուր ելքը ազդանշանից տարբերելու համար։ 1 կարգավիճակը Result=exit-code հետ միասին ծրագրի որոշում է. Result=signal կամ թայմաութը փոխարենը մատնանշում են միջավայրը, և պրոֆիլի խմբագրման ոչ մի քանակություն դա չի փոխի։ Գրանցեք երկու արժեքներն էլ նախքան որևէ բան վերագործարկելը, որովհետև վերագործարկումը ջնջում է այն անցողիկ վիճակը, որն առաջացրել է դրանք։

Instance-ի անունը ուղու մաս է

Փաթեթավորված ձևանմուշ unit-ը ֆայլի ուղի չի ընդունում։ Այն ընդունում է instance-ի անուն, և այդ անունը ավելացվում է մի պանակի՝ պրոֆիլը գտնելու համար. office-ը Debian և Ubuntu փաթեթավորման մեջ համապատասխանում է /etc/openvpn/client/office.conf ուղուն։ Ֆայլը, որի անունը office-v2.conf է և որը գործարկվել է որպես @office երբեք չի կարդացվում, և unit-ը լուռ դուրս է գալիս, որովհետև իր տեսանկյունից անելու բան չկար։ Որոնման պանակը տարբերվում է client և server ռեժիմներում, ուստի նույն սխալը ձևանմուշը փոխելիս մատնանշում է բոլորովին այլ տեղ։

Այս անհամապատասխանությունը լուռ ձախողման ամենատարածված աղբյուրն է, և այն անտեսանելի է պրոֆիլում, որովհետև պրոֆիլը կարգին է։ Թվարկեք, թե իրականում ինչ կա, և համեմատեք երկու անունները նշան առ նշան՝ ներառյալ ցանկացած ընդլայնում, որը փաթեթավորումը սպասում է։

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Եթե unit-ը միացված է, բայց ոչ մի instance նշված չէ, ապա ինքը միացումը կարող է հղում անել ավելի ուշ վերանվանված անվան։ Ճիշտ instance-ը նորից միացնելը սովորաբար բավարար է, և արժե ջնջել մնացած հին unit ֆայլը, որպեսզի այն չշփոթեցնի հաջորդ մարդուն։ Մնացած unit ֆայլը փոքր բան է, որը հետագայում ինչ-որ մեկին մեկ ժամ արժենա։

Երբ plugin-ը տիրում է թունելին, տերմինալը ոչինչ չի տեսնում

Desktop applet-ից սկսված կապը պատկանում է NetworkManager-ին, և դրա OpenVPN ելքը գնում է այդ ծառայության journal-ը, այլ ոչ թե ձեր բացած որևէ shell։ Client-ը ձեռքով գործարկելը և ոչինչ չտեսնելը այդ դասավորության մեջ սպասելի է, որովհետև ձեռքով գործարկված գործընթացը այն չէ, որ կրում է կապը։

Journal-ում գտեք այն ծառայությունը, որը տիրում է դրան, ապա վերարտադրեք վերլուծությունը ձեզ համար ընթեռնելի մանրամասնությամբ։ Ներքևի երկու հրամանները նայում են նույն ձախողման տարբեր տերերի։

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Առանձին գործարկումը նախատեսված է հաղորդագրություններ կարդալու համար, ոչ թե կառավարվող կապը փոխարինելու, և երկուսը հետագայում տարբերվում են. DNS ինտեգրումը, երթուղիները և կյանքի տևողությունը պատկանում են plugin-ին։ Առանձին գործարկման մեջ parse սխալը շտկելը ինքնաբերաբար չի շտկում անունների լուծումը, երբ applet-ը ստանձնում է, ուստի երկու դիտարկումները պահեք առանձին։

Երկու binary, մեկ PATH

Ձեռքով կառուցված տեղադրումը /usr/local տակ հաղթում է shell կանչի ժամանակ, որովհետև /usr/local/sbin նախորդում է /usr/sbin-ին Ubuntu-ի լռելյայն PATH-ում։ Unit-ը չի օգտագործում ձեր PATH-ը. այն գործարկում է ExecStart-ում գրված բացարձակ ուղին։ Այսպիսով, ձեր տերմինալում աշխատող տարբերակը և որպես ծառայություն ձախողվող տարբերակը կարող են իսկապես տարբեր ծրագրեր լինել։

Համեմատեք երկուսը նախքան որևէ բան վերակառուցելը։ Երրորդ հրամանն է, որ վճռում է վեճը։

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Եվս մեկ միջավայրի տարբերություն թաքնված է նույն տեղում։ Փաթեթավորված unit-ը հենվում է /run տակ գտնվող գործարման պանակի վրա, որը systemd-ը ստեղծում է նրա համար. ձեռքով գրված փոխարինող unit-ը, որը բաց է թողնում այդ կարգավորումը, կարող է ձախողվել նախքան մեկ ֆայլ բացելը, և ձախողումը նման է ընդհանուր մերժման՝ առանց OpenVPN հաղորդագրության։

Ձախողումներ, որոնց մասին client-ը չի կարող հայտնել

Որոշ արդյունքներ որոշվում են հեռավոր ծայրում։ Դարպասը, որը պատասխանում է HTTP կարգավիճակով և փակում կապը, ձեզ ասել է իր սեփական վիճակի մասին, և օգտակար հաջորդ քայլը նրա log-ն է կամ հավատարմագրի հետևում գտնվող հաշիվը, այլ ոչ թե ձեր տեղական ֆայլերը։ Այդ սցենարում տեղական ոչինչ կոտրված չէ, և փոխհատուցելու համար պրոֆիլը խմբագրելը դժվարացնում է հաջորդ ախտորոշումը։ Կարդացեք այդ log-ը նախքան client-ի կարգավորումը դնելը։

Մեկ այլ լուռ դեպք է ճիշտ աշխատող client-ը։ Client ռեժիմի թունելը երբեք պորտի վրա չի լսում, ուստի բաց լսող սպասող ստուգումը ոչինչ չի հայտնի և նման կլինի ձախողման։ Հաստատեք, թե որ ռեժիմն եք սկսել, նախքան դատարկ պորտերի ցանկից եզրակացություն անելը։

Աշխատեք շերտերը հերթականությամբ. արդյոք unit-ը գոյություն ունի և instance-ի անունը ճիշտ է, արդյոք ինչ-որ բան հասել է journal-ին կամ --log ֆայլին, որ binary-ն ու պրոֆիլն են իրականում աշխատել, և արդյոք ձախողումը տեղական է, թե հեռավոր։ Ամեն պատասխան հանում է մեկ շերտ։ Պրոֆիլից սկսելը նշանակում է վերագրել ֆայլ, որը միգուցե երբեք չի բացվել։