Ինչպես ստուգել OpenVPN պրոֆիլի սերվերը ներմուծելուց առաջ

Ինչ-որ մեկը ձեզ պրոֆիլ է ուղարկում, դուք ներմուծում եք այն, և երեսուն վայրկյան անց ինչ-որ հաճախորդ զանգահարում է մի նպատակակետ, որը ոչ ոք չի ստուգել։ Նախ կարդացեք ֆայլը տեքստային խմբագրում, որովհետև ամեն կարևորը տեղավորվում է մի բուռ հրահանգներում՝ remote, proto, port, ca, cert, tls-crypt և verify-x509-name։ Մնացած ամեն ինչ լռելյայն արժեքներ են, և հենց այնտեղ են ապրում անակնկալները։

Թվարկեք բոլոր վերջնակետերը, որոնք ֆայլը կարող է օգտագործել

Սկսեք վերջնակետերից, որովհետև մեկ պրոֆիլը կարող է պարունակել մի քանիսը։ grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn հրամանը տպում է յուրաքանչյուր թեկնածուի ֆայլի հերթականությամբ, ներառյալ ներդրված <connection> բլոկների ներսում գտնվողները։

Երբ հրահանգը բաց է թողնում պորտը, հաճախորդը վերադառնում է լսողի լռելյայն արժեքին, ուստի միայն remote vpn.example.com նշանակում է 1194 պորտ՝ ֆայլում ավելի ուշ հայտնված ցանկացած proto-ով։ Մի քանի պարզ remote տողեր այլընտրանքներ են. հաճախորդը փորձում է դրանք հերթականությամբ, եթե remote-random չի խառնում դրանք, և երբեք լուռ չի փոխարինում այլ օպերատորի հոսթը։ Անկապ տիրույթներում երկու remote տողն այն կետն է, որտեղ կանգնում եք և հարցնում, թե որն էր նկատի առնված։

Ուշադրություն դարձրեք նաև proto-ի ուղղագրությանը։ tcp ընդունվում է որպես հաճախորդի կողմի tcp-client-ի հոմանիշ, սակայն հաճախորդի պրոֆիլում tcp-server կազմաձևման սխալ է, որը հակված է կախվելու, քան մաքուր ձախողվելու։

Նախ հաստատեք անունը, ապա՝ պորտը

dig +short vpn.example.com հրամանը ձեզ ասում է՝ արդյոք անունը գոյություն ունի և ինչ հասցեներ է վերադարձնում, և բազմահասցե կամ պրոքսիի հետևում գտնվող վերջնակետը կարող է օրինականորեն մի քանիսը վերադարձնել։ Անվան լուծումը նախապայման է, ոչ թե սեփականության ապացույց. ցանկացած ոք կարող է անունը ուղղել հասցեի, և մեկ հասցեն կարող է պատասխանել շատ անունների համար։

Այնուհետև ստուգեք լսողին գտած պորտում՝ տրանսպորտային շերտին համապատասխան։ TCP-ի վրա openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com տպում է այն շղթան, որը ներկայացնում է սերվերը։ UDP-ի վրա ձեզ անհրաժեշտ է DTLS. openssl s_client -dtls1_2 -connect vpn.example.com:1194 կատարում է նույն ձեռքսեղմումը դատագրամների վրա։ Ավարտված ձեռքսեղմումը ապացուցում է, որ ինչ-որ բան լսում է և ունի վկայագիր, ինչը ավելին է, քան ցույց է տալիս ping-ը, և պակաս, քան պահանջում են պրոֆիլի սեփական վստահության կարգավորումները։

Երբ ձեռքսեղմումը ձախողվում է, իսկ հոսթը պատասխանում է ping-ին, պորտը հավանաբար սխալ է կամ զտված։ Ընդունեք դա որպես ճիշտ պորտը պահանջելու պատճառ, ոչ թե մերձակա պորտերը մաքրելու հրավեր։ nc -vzu-ը նույնպես որոշ ստեկերում հաջողություն է հաղորդում, երբ ոչինչ չի լսում, ուստի մերկ UDP փորձարկումը ոչինչ չի նշանակում առանց դրա հետևում ձեռքսեղմման։

Վստահության քորոցները կարդացեք հասցեից առանձին

Հասցեն որոշում է, թե ուր է գնում հաճախորդը. վստահության բլոկը որոշում է, թե ում է հավատում հասնելուց հետո։ verify-x509-name "vpn.example.com" name-ը ամրացնում է սուբյեկտի ընդհանուր անունը, իսկ remote-cert-tls server-ը պահանջում է ընդլայնված բանալու օգտագործում սերվերի նույնականացման համար։ Օպերատորի տված պրոֆիլը պետք է կրի երկուսն էլ։

Փնտրեք ca, ներդրված <ca> բլոկ և կամ tls-crypt, կամ tls-auth։ tls-auth օգտագործող պրոֆիլին հաճախորդի վրա անհրաժեշտ է key-direction 1, երբ սերվերի կողմը օգտագործում է 0 ուղղությունը, և անհամապատասխանությունը ձախողում է ձեռքսեղմումը TLS սխալով, որը կարդացվում է որպես վկայագրի թերություն։ Ներդրված CA, որը չի պատկանում այն օպերատորին, ում անունը հենց նոր լուծեցիք, նշանակում է, որ ֆայլը հավաքվել է երկու աղբյուրից, և հենց այդ դեպքն է, որ արժե վճռականորեն մերժել։

verify-x509-name-ն ընդունում է name, name-prefix կամ subject ռեժիմները, և վերջինը ակնկալում է ամբողջական տարբերակիչ անուն ճիշտ այն հերթականությամբ, որով սերվերը տպում է այն։ Ընտրեք ռեժիմ, որը համապատասխանում է արժեքի ձևին, որովհետև հաճախորդը մերժում է ամեն միացում՝ մոտ բացթողման մասին նախազգուշացնելու փոխարեն։ Ձեր չգրած ֆայլի համար պարզ հոսթանունով name-ը ամենաքիչ անակնկալ ընտրությունն է։

Ստուգեք այն ընտրանքները, որոնք լուռ ձախողվում են

OpenVPN 2.6-ը ծածկագրերը բանակցում է data-ciphers-ի միջոցով, և միայն հին cipher AES-256-CBC տող կրող պրոֆիլը կարող է ավարտել կառավարման ալիքը և ապա կանգ առնել տվյալների վրա։ Այդ արժեքը կարդալը ձեզ ասում է՝ արդյոք ֆայլը հին է այն սերվերից, որին միանում եք. 2.6-ի ձեռնարկի էջը թվարկում է բանակցությունների կարգը, եթե պետք է մեջբերեք այն օպերատորին։

Առանց ֆայլի անվան auth-user-pass նշանակում է, որ հաճախորդը կհարցնի, ուստի ինքնաբավ թվացող պրոֆիլը դեռ հավատարմագրեր է պահանջում։ auth-user-pass credentials.txt նշանակում է, որ այն սպասում է ֆայլի, որը հավանաբար ձեզ չեն ուղարկել։ nobind-ը և resolv-retry infinite-ը սովորական են և անվնաս, մինչդեռ explicit-exit-notify-ը միայն UDP-ի համար է և անօգուտ TCP-ի վրա։

Սրանցից ոչ մեկը չի փոխում, թե ուր է միանում պրոֆիլը, բայց յուրաքանչյուրը փոխում է, թե արդյոք այն ընդհանրապես կմիանա, և ոչ մեկը տեսանելի չէ հաճախորդի ներմուծման երկխոսությունում։

Որոշեք, ապա գրանցեք, թե ինչ որոշեցիք

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

Գրանցեք ձեր ստուգած հեշը, որպեսզի հաջորդ մարդը իմանա՝ արդյոք ֆայլը փոխվել է. sha256sum profile.ovpn, կպցված վերջնակետի կողքին ձեր նշումներում։ Պրոֆիլը ամբողջական դասավորություն է, ոչ թե հասցեների ցանկ, ուստի երբեք մի զետեղեք աշխատող remote-ը մեկ ուրիշի վստահության բլոկում՝ պահպանելով նրա հավատարմագրերը։

Մասնավոր բանալիներն ու գաղտնաբառերը պահեք էկրանի նկարներից և զրույցի թելերից դուրս, մինչ համեմատում եք նշումները։ Վերջնակետը և ոչ գաղտնի ընտրանքները բավական են ճշգրիտ հարց տալու համար, իսկ մնացածը տեղ ունի ֆայլում։

Եթե այնուամենայնիվ ներմուծեք այն և առաջին փորձը ձախողվի, գործարկեք հաճախորդը --verb 3-ով և կարդացեք առաջին տասը տողերը. լուծված remote հասցեն, բանակցված proto-ն և TLS սխալը հայտնվում են այդ հերթականությամբ, ինչը ձեզ ասում է, թե վերևի ստուգումներից որն եք բաց թողել։