Օգտագործեք ձեր գործող ձեռնարկության CA-ն OpenVPN հավասարակիցների համար
Easy-RSA-ն հարմարավետություն է, ոչ պահանջ։ Թողարկեք առանձին դերեր, միացրեք վստահության մուտքերը, հանձնեք միջանկյալ վկայագրերը և ապացուցեք, թե որ հավասարակիցներին է ընդունում թունելը։
OpenVPNում չի պահանջում, որ վկայագիրը գա Easy-RSA-ից, և արդեն կազմակերպչական PKI ունեցող պարկը սովորաբար չպետք է երկրորդը կառուցի։ Իրական աշխատանքը գործիք ընտրելը չէ, այլ որոշելը, թե ինչ են նշանակում թողարկված ինքնությունները, որ հավասարակիցներին է ընդունում թունելը և ինչպես են թարմացումն ու չեղարկումը հասնում ստուգողին։ Անցեք ստորև նշված հինգ քայլերը հերթականությամբ, որովհետև ավելի ուշ քայլը չի կարող շտկել առաջինում կայացված դերի որոշումը։
Թողարկեք երկու դեր մեկ ընդհանուր ինքնության փոխարեն
Յուրաքանչյուր հավասարակիցի անհրաժեշտ է սեփական վկայագիր և համապատասխան մասնավոր բանալի։ Խնդրեք PKI թիմին սերվերի օգտագործմամբ սերվերի ինքնություն և հաճախորդի օգտագործմամբ առանձին հաճախորդի ինքնություններ, որպեսզի թունելը ձեռքսեղմման պահին կարողանա տարբերել երկուսին։
Դիմացեք ժամկետների ճնշման տակ ի հայտ եկող կարճուղիներին։ Վեբ սերվերի բանալին նոթբուքերի վրա պատճենելը ջնջում է այն տարբերությունը, որի վրա հենվում է դերի ստուգումը, իսկ VPN վերջակետում տեղադրված CA ստորագրության բանալին մեկ վտանգված հոսթը վերածում է վտանգված հիերարխիայի։ PKCS12 փաթեթը կարող է կրել վերջակետի բանալին և դրա շղթան, բայց երբեք չի տալիս այդ ինքնությունը մեկ այլ դերում կրկնօգտագործելու թույլտվություն։
Միացրեք վստահության մուտքերը յուրաքանչյուր կողմում
Հաճախորդին և սերվերին յուրաքանչյուրին անհրաժեշտ է վստահության խարիսխ, սեփական ինքնություն և դերի բացահայտ սպասում։ Երեքն էլ նշող հաճախորդի հատվածը այսպիսի տեսք ունի։
client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crlՍերվերի կողմը դա արտացոլում է remote-cert-tls client-ով և իր վկայագրով, և հենց դա է խանգարում հաճախորդի վկայագիրը որպես սերվեր ընդունելուն։ Անվան ստուգումը դերի ստուգումից առանձին որոշում է։ Կարդացեք տեղակայված կազմաձևը՝ տեսնելու, թե որ դաշտն է համեմատվում, փոխանակ դիտարկիչային ոճի հոսթի անվան համընկնում ենթադրելու։ Երկու կողմերն էլ պետք է հստակ ասեն, թե որ թողարկողին են վստահում, որովհետև պարկով մեկ ընդհանուր ֆայլի ուղին նույնը չէ, ինչ ընդհանուր քաղաքականությունը։
Հանձնեք միջանկյալ վկայագրերը՝ չընդլայնելով վստահությունը
Երկու կողմերը պարտավոր չեն կիսել մեկ թողարկման շղթա։ Երբ հավասարակիցը ներկայացնում է միջանկյալով ստորագրված վկայագիր, ստուգող կողմին անհրաժեշտ է այդ միջանկյալը հասանելի, և OpenVPN-ը տարբերում է վստահության խարսխի մուտքը լոկալ ներկայացված շղթան լրացնելու համար օգտագործվող լրացուցիչ վկայագրերից։ OpenVPN 2.6-ի TLS ընտրանքների տեղեկատուն փաստագրում է երկուսն էլ։
Միջանկյալ CA-ն ինքնին խնդիր չէ, բայց վստահության փաթեթի մեջ նետված լայն ձեռնարկային արմատը խնդիր է։ Որքան լայն է խարիսխը, այնքան ավելի շատ վկայագրեր են անցնում շղթայի թեստը, և դերի ստուգումը դա չի վերածում լիազորված անձնակազմի ցանկի։ Նեղացրեք խարիսխը մինչև այն թողարկողը, որն իրականում ստորագրում է VPN ինքնությունները, որտեղ հիերարխիան թույլ է տալիս։ Եթե չի թույլ տալիս, փաստագրեք ավելի լայն խարիսխը որպես դիտավորյալ ընդունված ռիսկ՝ այն անուղղակի թողնելու փոխարեն։
Համաձայնեցրեք PKI թիմի հետ, թե ինչպես են թարմացումն ու չեղարկումը հասնում VPN ստուգողներին, ներառյալ, թե որ թողարկողներն են կարևոր և ով է հրապարակում ցանկը։ Վկայագրում ներկառուցված CRL բաշխման կետը հրահանգ է, ոչ թե ապացույց, որ ինչ-որ բան այն ներբեռնել է։
Որոշեք, թե ինչպես է չեղարկումը իրականում հասնում
crl-verify-ը ստուգողին ստիպում է դիմել ֆայլի կամ վերջակետի, և այդ կարգավորումը պահանջում է սեփականատեր և թարմացման ուղի։ Տեղակայման ընթացքում մեկ անգամ պատճենված ցանկը լուռ դադարում է պաշտպանել ձեզ, երբ առաջին անգամ վկայագիր չեղարկվի։
Գրեք ակնկալվող տարածման ժամանակը և փորձարկեք այն վկայագրով, որը պատրաստ եք չեղարկել։ Եթե ցանկը հնարավոր չէ թարմացնել VPN հոսթում, այլընտրանքը ավելի կարճ վավերականության ժամկետն է՝ գումարած իրականում աշխատող թարմացման գործընթաց, ոչ թե այն ենթադրությունը, որ չեղարկումն աշխատում է, քանի որ URL կա։
Ապացուցեք ընդունումը իրական հաճախորդով
Միացրեք հաճախորդ, որին պետք է թույլատրվի, և հաստատեք լոգում բանակցված վկայագրի մանրամասները։ Այնուհետև փորձեք այն դեպքերը, որոնք պետք է ձախողվեն՝ որպես սերվեր ներկայացված հաճախորդի վկայագիր, վստահության խարսխից դուրս թողարկողի վկայագիր, և չեղարկված վկայագիր, եթե ավելորդ մեկը ունեք։
Գրանցեք ընդունված թողարկողը, դերի ստուգումը և չեղարկման աղբյուրը պրոֆիլի կողքին։ Այդ գրանցումն այն է, ինչ անհրաժեշտ կլինի հաջորդ ինժեներին, երբ անցյալ ամիս աշխատող սարքը դադարի միանալ, և այն նաև ապացույցն է, որ ձեռնարկային CA-ն օգտագործվում է փաստաթղթավորված ընդունման սահմանի ներսում, ոչ թե որպես ընդհանուր նշանակության վստահության աղբանոց։