Ստուգեք VPN սերվերի վերականգնումը վերագործարկումից հետո. ինչ առաջինը ստուգել

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

Չորս սեփականատեր, չորս տարբեր թեստ

Վերագործարկումից առաջ անվանեք, թե ինչը պետք է վերադարձնի թունելը։ Ձեր գործարկած թեստը և կիրառած ուղղումը երկուսն էլ կախված են այդ պատասխանից, և կան չորս սովորական սեփականատերեր՝ systemd unit VPN-ի դեմոնի համար, wg-quick-ի օրինակի unit WireGuard-ի ինտերֆեյսի համար, կոնտեյների runtime կամ ցանցի կառավարչի պրոֆիլ։ Եթե չեք կարող անվանել սեփականատիրոջը, կանգ առեք և գտեք այն, որովհետև առանց սպասվող մեկնարկային ուղու վերագործարկման թեստը ձեզ միայն ասում է, որ ինչ-որ բան պատահել է։

Յուրաքանչյուր սեփականատեր իր կոնֆիգուրացիան պահում է այլ տեղ։ systemd-ով կառավարվող OpenVPN սերվերը կարդում է իր կոնֆիգուրացիան մեկնարկի պահին, ուստի այն, ինչ ֆայլում է բեռնման պահին, այն է, ինչ աշխատում է։ wg-quick ինտերֆեյսը իր հասցեները, երթուղիները և DNS-ը ստանում է նույն ֆայլից, ինչը նշանակում է, որ shell-ից ձեռքով բարձրացված և երբեք որպես unit չմիացված ինտերֆեյսը չի վերադառնա։ Կոնտեյները վերադարձնում է իր մուտքի կետը, բայց ոչ հոսթի firewall-ի փոփոխությունները, եթե դրանք ապրում են կոնտեյներից դուրս։

Նախ հիմնական վիճակը, այլապես արդյունքը ոչինչ չի նշանակում

Արձանագրեք աշխատող վիճակը, քանի դեռ այն աշխատում է՝ հասցեները թունելի վրա, երթուղիները հաճախորդի ենթացանցի համար, NAT կամ փոխանցման կանոնները, լսող սոքեթը և փոխանցման sysctl-ը։ ip addr show wg0, ip route, nft list ruleset կամ iptables-save, ss -lunp և sysctl net.ipv4.ip_forward բավարար են հոսթերի մեծ մասում։

Արձանագրեք, թե ինչպես է ծառայությունը կարգավորված մեկնարկելու համար, ոչ միայն այն, որ այն աշխատում է։ systemctl is-enabled wg-quick@wg0 և systemctl is-active wg-quick@wg0 պատասխանում են տարբեր հարցերի, և բեռնման պահին կարևոր է հենց միացված վիճակը, ինչպես նկարագրված է systemctl(1)-ում։ OpenVPN-ի համար ստուգեք, թե որ ձևանմուշն է օգտագործում հոսթը, որովհետև openvpn@server և openvpn-server@server տարբեր լռելյայններով տարբեր unit-ներ են։

Կատարեք վերագործարկումը և կարդացեք առաջին ձախողումը

Վերագործարկեք դիտավորյալ, ձեր ընտրած պատուհանի ընթացքում, բաց կոնսոլով կամ արտերգոտի ուղով։ Հետևեք իրադարձությունների հերթականությանը, ոչ թե վերջնական վիճակին՝ հոսթը հասանելի է, unit-ը ակտիվացված է, ինտերֆեյսը առկա է, երթուղիները տեղադրված են, firewall-ի կանոնները առկա են, լսողը կապված է, հաճախորդը ընդունված է։ Առաջին քայլը, որը տեղի չի ունենում, հենց գտածո է; մնացած ամեն ինչ աղմուկ է։

Դեմոնը կարող է ակտիվ լինել, մինչ թունելը անօգտագործելի է, և սա ամենատարածված կեղծ անցումն է։ Մեկնարկը կարող է ավարտվել նախքան ցանցը առցանց դառնալը, եթե unit-ը սպասում է միայն network.target-ին, այլ ոչ network-online.target-ին։ Հիշատակված ֆայլերը, ինչպիսիք են վկայագրերը, բանալիները կամ CRL-ը, այդ պահին կարող են անընթեռնելի լինել, որովհետև mount-ը կամ գաղտնիքների ուղին դեռ պատրաստ չէ։ Երկու խնդիրներից ոչ մեկը չի երևում systemctl status-ում, քանի դեռ չեք կարդացել unit-ի մատյանը։

Փորձարկեք հոսթից դուրս։ Նույն LAN-ի հաճախորդը կարող է հաջողության հասնել այնպիսի երթուղով, որը ոչ մի հեռավոր հաճախորդ երբեք չէր օգտագործի, և դեպի մեքենա SSH սեսիան ոչինչ չի ապացուցում թունելի մասին։ Միացեք, լուծեք ներքին անուն, հասեք մասնավոր ռեսուրսին, ապա նորից միացեք մեկ անգամ՝ հաստատելու, որ չեղարկման վիճակը և բանալիները դեռ կիրառելի են։

Երեք պայմանները, որոնք որոշում են ձեր ուղղումը

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

Կատարեք ուղղումը այնտեղ, որտեղ կարգավորումը սեփականություն է։ Դրեք փոխանցումը sysctl drop-in-ի մեջ, NAT-ի կանոնները՝ բեռնման պահին բեռնվող կանոնների հավաքածուի մեջ, միացրեք unit-ը՝ այն մեկնարկելու փոխարեն, և պահեք գաղտնիքները այնպիսի ուղու վրա, որը գոյություն ունի unit-ի մեկնարկից առաջ։ Unit-ին քուն ավելացնելը թաքցնում է կախվածությունը՝ այն հռչակելու փոխարեն։

Արձանագրեք արդյունքը runbook-ում

Գրեք, թե ինչ վերադարձավ ինքնուրույն, ինչ ստիպված էիք մեկնարկել, և որքան տևեց բացը։ Ներառեք ստուգման համար օգտագործած ճշգրիտ հրամանները, որպեսզի հաջորդ մարդը կրկնի թեստը՝ նորը հորինելու փոխարեն։ Եթե որևէ քայլ պահանջել է ձեռքի հրաման, այդ հրամանը պատկանում է կոնֆիգուրացիային, ոչ թե runbook-ին որպես մշտական քայլ։

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