Մերժված միացումը վկայագրի խնդիր չէ. VPN-ի գործառնական ուղեցույց

Հաճախորդը ասում է, որ միացումը մերժվել է CRL-ը վերականգնելուց անմիջապես հետո, ուստի CRL-ը մեղավոր է թվում։ Այդպես չէ։ Մերժումը տրանսպորտային շերտի պատասխանն է, իսկ վկայագրի ստուգումը տեղի է ունենում ավելի ուշ՝ թունելի ձեռքսեղմման մեջ։ Ժամանակի համընկնումը համատեքստ է, ոչ ապացույց։

Երկու ստուգում մեկ րոպեից պակաս ժամանակում բաժանում են դեպքերը, և դրանցից ոչ մեկը չի դիպչում վստահության կարգավորումներին։

Կարդացեք սխալը այն շերտում, որը ստեղծել է այն

connect-ից ECONNREFUSED նշանակում է, որ տրանսպորտային փորձը մերժվել է. ինչ-որ բան պատասխանել է reset-ով, կամ ստեկը հաղորդել է անհասանելի պորտի մասին։ Վկայագրի խնդիրը չի կարող առաջացնել այդ սխալը, քանի որ TLS ձեռքսեղմումը երբեք չի սկսվում առանց տրանսպորտային միացման։ Եթե տեսնում եք մերժում, հաճախորդը երբեք չի հասել վկայագիր ներկայացնելու աստիճանին։ Այդ մեկ փաստը բացառում է չեղարկումը որպես պատճառ։

Ճիշտ է նաև հակառակը։ Չեղարկված վկայագիրը առաջացնում է ավարտված TCP միացում և ձախողված ձեռքսեղմում, որը սերվերում գրանցվում է որպես ստուգման սխալ։

TCP մերժում. ոչ ոք չի լսում

TCP-ի համար ստուգեք, թե արդյոք նախատեսված օրինակը աշխատում է և կապված է պրոֆիլի հասցեին ու պորտին։ ss -lntp ցույց է տալիս լսողներին, և դրանց բացակայությունը սովորական բացատրությունն է։ Հրման պատը, որը մերժում է՝ փոխանակ գցելու, առաջացնում է նույն հաղորդագրությունը հաճախորդի կողմում, դրա համար ստուգում եք երկուսն էլ։

Ստուգեք նաև հասցեների ընտանիքը։ 127.0.0.1-ին կամ միայն IPv6-ին կապված ծառայությունը կմերժի այն հաճախորդին, որը լուծվում է մյուսին։

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

UDP-ն ձեռքսեղմում չունի մերժելու համար

OpenVPN-ը UDP-ով TCP իմաստով միացում չի հաստատում, ուստի connect-ի պահին մերժելու բան չկա։ Linux-ում UDP սոկետի ցուցադրած սխալը կարող է գալ ավելի վաղ դատագրամի կողմից ստեղծված ICMP port-unreachable-ից։ udp(7) ուղեցույցի էջը նկարագրում է այդ ասինքրոն վարքը։

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

Որտեղ է իրականում ստուգվում CRL-ը

CRL-ը խորհրդակցվում է TLS ձեռքսեղմման ընթացքում՝ այն բանից հետո, երբ կողմը ներկայացնում է իր վկայագիրը, և միայն եթե սերվերի կազմաձևը դա թույլ է տալիս։ OpenVPN-ի crl-verify ընտրանքը ցույց է տալիս ֆայլը, և ձախողումը սերվերի մատյանում հայտնվում է որպես ստուգման սխալ՝ նշելով վկայագիրը։

Ուստի չեղարկված հաճախորդը միանում է տրանսպորտային շերտում և ապա ձախողում նույնականացմանը։ Նույն սերվերը, նույն պորտը, բոլորովին այլ հաղորդագրություն։

Երբ հասնեք այդ փուլին, ստուգեք CRL-ի թողարկողին և վավերականության ամսաթվերը։ Սխալ CA-ի կողմից ստորագրված CRL-ը, կամ այն, որ լրացել է հաճախորդի միանալուց առաջ, առաջացնում է ստուգման սխալներ, որոնք ոչ մի կապ չունեն հաճախորդի սեփական վկայագրի հետ։

Կարճ ուղեցույց հաջորդ անգամվա համար

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

Գրի առեք տրանսպորտը, լուծված նպատակակետը, պորտը և սխալի ճշգրիտ տեքստը։ Հաճախորդի վերատեղադրումը ոչնչացնում է այդ ապացույցը և սովորաբար ոչինչ չի փոխում։