Ո՞ր OpenVPN պատճենն է իրականում օգտագործում ձեր PiVPN պրոֆիլը։

PiVPN-ը գրում է սերվերի կարգավորում և հաճախորդի պրոֆիլ, ապա դուրս է գալիս. այն երբեք չի դառնում այն գործընթացը, որը տանում է ձեր երթևեկությունը։ Այդ պատճառով ձախողված ձեռքսեղմումը, սխալ վերջնակետին զանգահարող հաճախորդը կամ վերամեկնարկից հետո սխալ վերադարձող ծառայությունը չեն կարող բացատրվել տեղադրողի ընտրացանկերից։ Այդ ախտանիշները պատկանում են այն OpenVPN դեմոնին, որն այժմ աշխատում է, այն կարգավորմանը, որը դեմոնն իրականում բեռնել է, և այն մատյանին, որին այն ուղղված է։ Չորս միայն-կարդալու հրաման սովորաբար լուծում են դա, և դրանցից ոչ մեկը չի փոխում ձեր վկայագրերը կամ բանալիները։

Օգնականը և դեմոնը տարբեր օբյեկտներ են

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

systemd հոսթի վրա սկսեք ակտիվ միավորից, ոչ թե պանակի ցանկից։ Անունը կախված է փաթեթավորումից. Debian-ի և Raspberry Pi OS-ի պատկերները սովորաբար առաջարկում են ձևանմուշային օրինակ, օրինակ՝ openvpn-server@server, մինչդեռ ավելի հին տեղադրումները օգտագործում են openvpn@server։ Հարցրեք կառավարչին, թե որն է աշխատում, փոխարենը ֆայլի անունից գուշակելու։

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Կարդացեք ExecStart= տողը այդ ելքի մեջ։ Այն նշում է կատարվող ֆայլը և այն ընտրանքները, որոնք կառավարիչն իրականում գործարկում է, ներառյալ ցանկացած --config ուղի. կողքին ընկած կարգավորման ֆայլը, որին ոչ մի հրաման չի հղում, աշխատող թունելի մաս չէ։

Հետևեք այն կարգավորման շղթային, որը լուծել է դեմոնը

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

Նախ արտածեք փաստացի կանչը, ապա նայեք ինքնությունը և հասանելիությունը որոշող հրահանգներին։ Երկու հրամաններն էլ միայն-կարդալու են և անվտանգ կենդանի սերվերի վրա, թեև երկրորդը տպում է ուղիներ, որոնք գուցե չեք ուզում հանրային տոմսում։

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Տնային պանակում գտնվող .ovpn ֆայլը հաճախորդի արտեֆակտ է։ Սերվերի դեմոնը երբեք չի կարդում այն, ուստի այդ ֆայլը խմբագրելը սերվերային ձեռքսեղմման ձախողումը շտկելու համար ոչինչ չի տալիս։

Ներառումները մյուս թակարդն են։ Մի config տող ներգրավում է երկրորդ ֆայլ, որի ընտրանքները մշակվում են այդ պահին, ուստի ավելի ուշ միարժեք հրահանգը կարող է վերագրել այն, ինչ հիմնական ֆայլը կարծես թե ասում է։ Եթե տեսանելի ֆայլը ճիշտ է թվում, իսկ դեմոնը դեռ այլ կերպ է վարվում, կարդացեք ներառված ֆայլը նախքան որևէ բան փոխելը։

Մատյանը կապեք գործընթացի հետ, ոչ թե այն սխալի, որը հիշում եք

Երկու մատյանի նպատակակետ սովորական են, և դրանցից միայն մեկն է journal-ը։ log-append սահմանված լինելու դեպքում դեմոնը գրում է այդ ֆայլին, և journal-ը պահում է քիչ բան՝ բացի գործարկման տողերից։ Առանց դրա journalctl իրադարձությունների աղբյուրն է։

journalctl -u openvpn-server@server -n 80 --no-pager

Կապակցեք միացման մեկ փորձը մեկ ժամանակային պատուհանի հետ։ Նշեք հաճախորդի վերջնակետը, ապա կարդացեք սերվերի իրադարձությունները նույն վայրկյաններից։ TLS ձեռքսեղմումը, որը երբեք չի հասնում վկայագրերի փոխանակմանը, ցույց է տալիս հասանելիության կամ արձանագրության անհամապատասխանության մասին, մինչդեռ նույնականացման մերժումը գալիս է այն բանից հետո, երբ թունելի պարամետրերն արդեն համաձայնեցված են։

Հին մատյանի գրառումը ոչինչ չի ապացուցում հինգ րոպե առաջ ներբեռնված պրոֆիլի մասին։ Կրկին ստեղծեք հաճախորդի ֆայլը, միացեք մեկ անգամ, և կարդացեք միայն այն տողերը, որոնք հայտնվեցին այդ փորձի ընթացքում։

Գրանցեք առաջին կոնկրետ ձախողումը, ոչ թե վերջին ընդհանուրը։ Կապակցման սխալը, անպատասխան արտաքին փոխանակումը, վկայագրի մերժումը և հաշվի մերժումը յուրաքանչյուրը ձեզ ուղարկում է այլ շերտ, և վերջում ժամանակի սպառումը հաճախ թաքցնում է վերևի օգտակար իրադարձությունը։

Թունելի վերակառուցումը ախտորոշիչ քայլ չէ

Գայթակղիչ կարճ ուղին երկրորդ, ավելի պարզ թունել կանգնեցնելն է. ստատիկ բանալի, առանց վկայագրերի, առանց լրացուցիչ նույնականացման։ Այն հաճախ կմիանա, և դա ապացուցում է միայն, որ երկու հոսթ կարող են UDP կամ TCP անցկացնել իրենց միջև։ Այն ոչինչ չի ասում, թե ինչու է վկայագրերով նույնականացված տեղակայումը ձախողվում, և լուռ փոխարինում է այն անվտանգության մոդելը, որը ձեզ խնդրել էին պահել։

Նույնը վերաբերում է tls-auth կամ tls-crypt անջատելուն, verify-x509-name թուլացնելուն, կամ կանաչ կարգավիճակի համար երկրորդ գործոնը բաց թողնելուն։ Թունելը, որը միանում է, որովհետև ստուգումը հեռացվել է, այլ համակարգ է, ոչ թե վերանորոգված։

Կատարեք մեկ սահմանափակ փոփոխություն այն շերտում, որը նշել է մատյանը, վերագործարկեք նույն միավորը, և կրկնեք միակ միացման փորձը։ Դա պահում է համեմատությունը ազնիվ և թողնում է փոփոխություն, որը կարող եք հետարկել։

Ինչ փոխանցել հաջորդ մարդուն

Գրեք չորս փաստ, քանի դեռ դրանք ձեզ մոտ են. OpenVPN-ի տարբերակը openvpn --version հրամանի արդյունքից, ակտիվ միավորը, կարգավորման շղթան իր ներառումներով, և մեկ փորձ ծածկող մատյանի պատուհանը։ Այդ չորսը մշուշոտ բողոքը դարձնում են վերարտադրելի դեպք։

Կրճատեք նախքան կիսվելը։ Մասնավոր բանալիները, auth-user-pass ֆայլերը, ստատիկ բանալու նյութը և ամբողջական հաճախորդային փաթեթները տեղ չունեն տոմսում. ընտրանքների անունները և շղթայի ձևը սովորաբար բավական են երկրորդ զույգ աչքերի համար։

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