Հին .ovpn պրոֆիլը ձախողվում է Ubuntu 24.04-ում. որ տողերը ջնջել

Պրոֆիլը ներբեռնվում է, ներմուծվում, ապա կանգ է առնում ֆայլի 12-րդ տողում Unrecognized option հաղորդագրությամբ, որը նշում է keysize։ Հաշվի հետ կապված ոչինչ չի փոխվել, և սերվերը դեռ ընդունում է այլ հաճախորդների։ Փոխվել է հենց հաճախորդը. Ubuntu 24.04-ը տեղադրում է OpenVPN 2.6, մինչդեռ արտահանումը գրվել է 2.4-ի համար։ Ուղղումը ջնջումների կարճ շարք է, և հերթականությունը կարևոր է, որովհետև յուրաքանչյուր հնացած ընտրանք դադարեցնում է վերլուծությունը նախքան հաջորդի ընթերցվելը։

Կարդացեք սխալի տողը նախքան ֆայլին դիպչելը

OpenVPN-ը նշում է ֆայլը և տողը, որտեղ կանգ է առել վերլուծությունը, ուստի մեկ գործարկման ընթացքում կարող եք շտկել միայն մեկ խնդիր։ Գործարկեք պրոֆիլը տերմինալից, ոչ թե աշխատանքային սեղանի հավելվածից, որովհետև հավելվածը սովորաբար կուլ է տալիս stderr-ը, և տողի համարը ստացած միակ վստահելի ցուցիչն է. sudo openvpn --config /etc/openvpn/client/provider.ovpn։ Ուղղեք այդ տողը, գործարկեք նորից և սպասեք, որ հաջորդ ձախողումը կնշի այլ ընտրանք։

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

Ձախողման երեք դաս, երեք տարբեր ուղղում

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

• Վերլուծության սխալները նշում են ֆայլ և տող և կանգ են առնում նախքան որևէ երթևեկության առաջանալը։
• Բանակցությունների սխալները միանում են, ապա հայտնում, որ երկու ծայրերը չկարողացան պայմանավորվել ընդհանուր գաղտնագրման կամ ընդունելի տվյալների ուղու շուրջ։
• Նույնականացման սխալները հասնում են ամենահեռու և նշում վկայական, օգտատեր կամ մերժված հավատարմագիր։

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

Ջնջեք 2.6-ի հեռացրած ընտրանքները այս հերթականությամբ

Այս տողերից յուրաքանչյուրն ինքնուրույն դադարեցնում է վերլուծությունը, ուստի հաճախորդը հաղորդում է դրանց մեկ առ մեկ։ Անցեք ցուցակով ներքև և յուրաքանչյուր ջնջումից հետո գործարկեք նորից։

Նախ ջնջեք keysize-ը, որովհետև այն ժամանակակից համարժեք չունի, և դրա առկայությունը սովորաբար նշում է գաղտնագրում, որն ընթացիկ հաճախորդը միևնույն է մերժում է։ Ապա ջնջեք ncp-disable-ը, որը կառավարում էր գաղտնագրման բանակցությունը, հնացավ 2.5-ում և բացակայում է 2.6-ում։ Փոխարինեք ns-cert-type server-ը remote-cert-tls server-ով, որը նույն մտադրությունն է արտահայտում աջակցվող ստուգման միջոցով։ 2.6-ի փոփոխությունների պատմությունը թվարկում է մնացած հեռացումները դրանց փոխարինիչների կողքին, ուստի ամեն ինչ, ինչ վերլուծիչը դեռ մերժում է, ունի փաստաթղթավորված պատասխան։

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

BF-CBC-ն աշխատեցրեք միայն որպես սահմանափակ պահուստ

Որոշ մատակարարներ դեռ ավարտում են BF-CBC-ով, որի շուրջ OpenVPN 2.6-ը առանց օգնության չի բանակցի, որովհետև գաղտնագրման բլոկը 64 բիթ է։ Նեղ ուղղումը պահուստային ցուցակն ու OpenSSL-ի հին մատակարարն են, ոչ ամբողջ հաճախորդի իջեցումը։

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

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

Չդիմեք --compat-mode-ին որպես համընդհանուր պատասխան։ Այն միանգամից փոխում է մի քանի վարքագիծ, ներառյալ բանակցությունների և վերաբանակցությունների լռելյայն արժեքները, ուստի երբեք չեք իմանա, թե որ փոփոխությունն էր կարևոր։ Նախընտրեք վերևի երեք հստակ տողերը, որովհետև յուրաքանչյուրը հայտնում է իր ազդեցությունը։

Ստուգեք այն պրոֆիլով, որը հաճախորդն իրականում բեռնում է

Ներմուծված միացումները հաճախ պատճենվում են համակարգային պանակում, ուստի ձեր ներբեռնումների պանակի ֆայլը խմբագրելը կարող է ոչինչ չփոխել։ Գտեք այն պատճենը, որն աշխատում է. sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn։ Ապա գործարկեք թունելը և կարդացեք մատյանի այն տողը, որը հաղորդում է, թե տվյալների ուղու որ գաղտնագրումն է իրականում ընտրվել։ Պահուստի վրա ձեռքսեղմումն ավարտող միացումը ձեզ ասում է, որ սերվերը երբեք ժամանակակից ոչինչ չի առաջարկել։

Փորձարկեք ցանցից, որը մատակարարի սպասված ցանցը չէ, որպեսզի որևէ գերեվարված պորտալ կամ զտված հյուրային ցանց պրոֆիլի անսարքություն չձևացնի։ Գրանցեք հաճախորդի տարբերակը ցանկացած աջակցության հարցումի հետ միասին։

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