Ինչու Cloudflare-ի փրոքսին չի կարող OpenVPN-ը կրել մեկ անվան վրա

Մեկ մեքենա վարում է կայքը և OpenVPN սերվերը, և գայթակղությունն այն է, որ մեկ հոսթային անուն ուղղենք դեպի այն և թողնենք նարնջագույն ամպին կարգավորել երթևեկությունը։ Փրոքսին կարգավորում է HTTP-ը և HTTPS-ը։ Այն չի կարգավորում OpenVPN սեսիան, անկախ նրանից, թե այդ սեսիան որ պորտն է օգտագործում։ Երկու անուն՝ մեկը ուղիղ, մյուսը փրոքսիով, ոչինչ չեն արժեն և հեռացնում են շփոթության ամբողջ դասը։

Երկու անուն, երկու փոխադրում

Կայքին տվեք փրոքսիով գրառում, որպեսզի նրա HTTP և HTTPS երթևեկությունն անցնի Cloudflare-ով։ VPN-ին տվեք միայն-DNS գրառում, որը լուծվում է ուղիղ դեպի հանրային VPN մուտքը, և թողեք հաճախորդին օգտագործել այն UDP կամ TCP պորտը, որի համար կարգավորված է։

Երկու անուններն էլ կարող են հայտնվել նույն սկզբնաղբյուր մեքենայի վրա։ Տարբերությունը նրանում է, թե ինչ է կատարվում հաճախորդի և այդ մեքենայի միջև, և այդ տարբերությունն է բաժանման իմաստը։

Cloudflare-ի ցանցային պորտերի տեղեկագիրը թվարկում է, թե սովորական վեբ փրոքսին որ պորտերն է ընդունում։ Այդ ցանկը վերաբերում է այդ պորտերի վրա HTTP-ին և HTTPS-ին, ոչ թե կամայական արձանագրություններին, որոնք պատահաբար կիսում են մի թիվ։

Պորտը արձանագրությունը չէ

OpenVPN-ը TCP 443-ին տեղափոխելը այն HTTPS չի դարձնում։ Փրոքսին դեռ սպասում է HTTP հարցում միացման սկզբում, իսկ OpenVPN հաճախորդը դրա փոխարեն ուղարկում է երկուական կառավարման հաղորդագրություն։ Միացումը ձախողվում է այնպես, որ նման է ցանցային արգելափակման, որովհետև ոչ մի օգտակար բան չի հասնում մատյան։

Եթե պահանջը իրոք VPN-ի տվյալների ուղու մեջ Cloudflare ապրանք տեղադրելն է, գնահատեք այնպիսին, որը փաստագրում է ձեզ անհրաժեշտ արձանագրության աջակցությունը։ Մի՛ ենթադրեք, որ նարնջագույն ամպը ընդհանուր TCP կամ UDP թունել է, որովհետև այն վեբ երթևեկության հակադարձ փրոքսի է՝ հատուկ առաջադրանքով։

Միայն-DNS գրառումը ձանձրալի պատասխանն է, որն աշխատում է, և հենց նրան պետք է առաջինը դիմել։

Մեկ մեքենային դեռ պետք է երկու լսող

Առանձին անունները թույլ չեն տալիս երկու գործընթացների միաժամանակ զբաղեցնել նույն հասցեն, պորտը և փոխադրումը։ Եթե վեբ սերվերն արդեն բոլոր հասցեներում զբաղեցնում է TCP 443-ը, OpenVPN օրինակը չի կարող այն նույնպես վերցնել առանց դիտավորյալ պայմանավորվածության։

Կապեք VPN լսողը այլ պորտի, կամ այլ հասցեի, կամ առջևում դրեք փաստագրված մուլտիպլեքսոր և ընդունեք դրա հետ եկող գործառնական ծախսը։ Այդ ընտրություններից յուրաքանչյուրը պետք է երևա firewall-ի կանոններում, որովհետև այն լսողը, որը ոչ ոք չի փաստագրել, հենց այն է, որը բաց թողնվում է միջադեպի ժամանակ։ Գրեք ընտրված կապումը նույն runbook-ում, որը նկարագրում է թունելը։ Այն ժամանակ հաջորդ մարդը գիշերվա ժամը երկուսին նորից չի հայտնաբերի այն։

Վկայականները հետևում են այն միացմանը, որը պաշտպանում են

Բրաուզերի TLS միացումը Cloudflare-ին և Cloudflare-ի միացումը ձեր սկզբնաղբյուրին երկու առանձին հարաբերություններ են՝ երկու առանձին վկայականներով։ Բրաուզերը տեսնում է եզրային վկայական։ Սկզբնաղբյուրը ներկայացնում է իր վկայականը Cloudflare-ին, և Cloudflare Origin CA վկայականը նախատեսված է հենց այդ երկրորդ հարաբերության համար։

Cloudflare-ը վստահում է այդ սկզբնաղբյուրի վկայականին Full (strict) ռեժիմում, և դա ընդհանուր վստահելի բրաուզերի վկայական չէ։ Եթե ինչ-որ մեկը ուղիղ այցելի միայն-DNS հոսթային անունը և նախազգուշացում ստանա, դա վստահության փոխված ուղու սպասված հետևանքն է, ոչ թե ապացույց, որ գաղտնագրումը դադարել է։

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

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

Բացահայտումը հետևում է անվանը

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

Որոշեք, թե որ վեբ հարցումները կարող են ուղիղ հասնել սկզբնաղբյուրին, և դա կիրառեք սկզբնաղբյուրում, ապա թույլ տվեք VPN լսողին իր սեփական պայմաններով։ Կառավարման էջերը, պրոֆիլների ներբեռնումները և տվյալների լսողը կարող են ունենալ երեք տարբեր բացահայտման պահանջներ, նույնիսկ երբ մեկ փաթեթը տրամադրում է բոլոր երեքը։

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

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