Սպանված openconnect. երթուղիները և DNS-ը դեռ ցույց են տալիս թունելին

Թունելն անջատված է, բայց մեքենան դեռ վարվում է այնպես, կարծես այն միացած է. հարցումը կախված է մնում մինչև ժամկետի լրանալը, և երթուղին ցույց է տալիս մի ինտերֆեյսի, որն այլևս չկա։ Սա openconnect գործընթացի ստորագրությունն է, որը մահացել է առանց իր անջատման օգնականը գործարկելու։ Այն ցանցային վիճակը, որը ստեղծել է, դեռ տեղադրված է, և համակարգում ոչ մի այլ բան չգիտի, թե ինչպես այն հեռացնել։

Անցեք մեքենայով այն հերթականությամբ, որով ստեղծվել է վիճակը. գործընթաց, կապ, երթուղի, resolver։ Յուրաքանչյուր քայլ ասում է՝ հաճախորդն իսկապես գնացե՞լ է, թե միայն ձեր տերմինալից է անջատվել, և այդ տարբերությունը որոշում է՝ արդյոք ընդհանրապես ինչ-որ բան վերանորոգեք։

Սկսեք գործընթացից, ոչ թե կոնֆիգուրացիայից

Բացեք տերմինալ և հարցրեք, թե ինչ է դեռ աշխատում, նախքան երթուղուն դիպչելը։ pgrep -a openconnect թվարկում է յուրաքանչյուր օրինակն իր արգումենտներով, ինչը ցույց է տալիս pid ֆայլը և դրան տրված սկրիպտը։ Չսպասված գործընթացը ֆանտոմ թունելը բացատրում է ավելի արագ, քան ցանկացած լոգ։

Եթե ոչինչ չի աշխատում, նայեք կապին։ ip link show tun0 ասում է՝ ինտերֆեյսը ողջ է մնացել, և ip route show dev tun0 թվարկում է երթուղիները, որոնք դեռ կապված են դրան։ Այնուհետև ստուգեք resolver-ը այսով resolvectl status։ Գրանցեք բոլոր երեք ելքերը նախքան դրանք փոխելը, որովհետև հենց այդ գրառումն է, որով ավելի ուշ կտարբերեք հնացած մուտքը նորից։

Անհետացող ինտերֆեյսը սովորաբար իր հետ տանում է իր երթուղիները։ Կապից հետո մնացող երթուղիները սովորաբար նշանակում են, որ գործընթացը դեռ կենդանի է, կամ սարքը պատկանում է երկրորդ հաճախորդի։

Հենց օգնական սկրիպտն է, որ հետ է շրջում փոփոխությունները

openconnect-ն ինքը չի հեռացնում ինտերֆեյսը, երթուղիները կամ resolver-ի գրառումները։ Այն կանչում է արտաքին օգնական, /etc/vpnc/vpnc-script upstream build-ում և /usr/share/vpnc-scripts/vpnc-script Debian և Ubuntu փաթեթներում, ընտրված այսով -s։ Նույն սկրիպտը, որը կանգնեցնում է թունելը, այն է, որ քանդում է այն։

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

Թե որ ազդանշանն է հասնում այդ ուղուն, փոխվել է տարբերակների միջև։ 7.06 ձեռնարկը SIGTERM-ը համարում է անմիջական ելք, որը բաց է թողնում սկրիպտը։ Ընթացիկ build-երը փաստագրում են INT-ը և TERM-ը որպես մաքուր կանգառ, որտեղ նստաշրջանը դուրս է գրվում և օգնականն աշխատում է։ Կարդացեք այն բինար ֆայլի SIGNALS բաժինը, որն իրականում ունեք, փոխարենը չենթադրելով վարքագծերից որևէ մեկը։

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Ուղարկեք այն ազդանշանը, որը փաստագրում է ձեր build-ը

Երբ իմանաք ազդանշանը, կանգնեցրեք գործընթացը pid-ով, ոչ թե նախշով։

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Այնուհետև կրկնեք առաջին բաժնի երեք ստուգումները՝ ելքի կարգավիճակին վստահելու փոխարեն։ ip link show tun0 պետք է ձախողվի, ip route show dev tun0 ոչինչ չպետք է տպի, և resolvectl status այլևս չպետք է թվարկի VPN կապը։

SIGHUP-ը կանգառի կոճակ չէ. այն անջատում է, գործարկում սկրիպտը և նստաշրջանը թողնում վերսկսելի այսով --cookie։ SIGUSR2-ը պարտադրում է անմիջական վերակապում։ SIGKILL-ը ամբողջովին բաց է թողնում մաքրումը, և դա հենց այն վիճակն է, որի մասին է այս հոդվածը։

Վերանորոգեք resolver-ը առանց resolv.conf-ը փոխարինելու

Ubuntu-ի համակարգերի մեծ մասում /etc/resolv.conf systemd-resolved-ի խորհրդանշական հղում է, ոչ թե ֆայլ, որը պետք է խմբագրեք։ Այն փոխարինելը կոտրում է անունների լուծումը բոլոր ցանցերի համար, ոչ միայն VPN-ի։ Փոխարենը հեռացրեք թունելի գրանցումը.

resolvectl revert tun0
resolvectl query example.com

Եթե համակարգը systemd-resolved-ի փոխարեն օգտագործում է resolvconf, ինտերֆեյսի գրառումը մնում է այնքան ժամանակ, մինչև նրան ասեն բաց թողնել կապը, և resolvconf -d tun0 համարժեք գործողությունն է։ Ստուգեք, թե որ resolver-ն է օգտագործվում, նախքան հրամանը ընտրելը։

Հարցումը, որը դեռ ուղղված է մեռած կապի հետևում գտնվող սերվերին, կախված է մնում մինչև ժամկետի լրանալը, և այդ ուշացումը ավելի շատ կոտրված DNS սերվերի է նման, քան մնացորդային երթուղու։

Հաջորդ անջատումը ձանձրալի դարձրեք

pid ֆայլի ուղին նույնը պահեք գործարկման և անջատման ժամանակ՝ փոխանցելով --pid-file ամեն անգամ, կամ գործարկեք openconnect-ը unit-ի ներքո որի KillSignal համապատասխանում է այն ազդանշանին, որը փաստագրում է ձեր տարբերակը։ Առաջինը foreground-ում փորձարկելը ցույց է տալիս անջատման հաղորդագրությունները, որոնք տպում է օգնականը։

Միացեք, անջատվեք և մեկ անգամ գործարկեք երեք ստուգումները։ Մաքուր ելքը ոչ VPN կապ է թողնում, ոչ VPN երթուղի, ոչ VPN resolver-ի գրառում։ Եթե երեքից մեկը ողջ մնա, այժմ գիտեք, թե որ բաղադրիչը չմաքրեց։ Հաջորդ հետաքննությունն այդ դեպքում սկսվում է այդ պատասխանից, ոչ թե կախված հարցումից։