Սերվերին կցված պրոֆիլը ձախողվում է TLS փրոքսիի հետևում. որ սերունդը։
Access Server 2.8-ը և 2.9-ը սերվերին կցված պրոֆիլները կառուցում են տարբեր կերպ։ Որոշեք, թե ձեր փրոքսին որ ուղին է կոտրում, նախքան ճակատային մասը փոխելը։
Մի օգտատեր կարող է միանալ, մյուսը՝ ոչ, նույն պորտալով, նույն օրը։ Երկուսն էլ ունեն սերվերին կցված պրոֆիլներ, երկուսն էլ նույն Access Server հավաքածուի վրա են, և միակ տարբերությունն այն է, թե երբ է ստեղծվել նրանց պրոֆիլը։ Սա այն օրինաչափությունն է, որն արժե ճանաչել, որովհետև "սերվերին կցված" անվանում է քաղաքականություն, ոչ թե միացման հաջորդականություն։ Access Server-ը թողարկել է այդ արտեֆակտի երկու սերունդ, և TLS հակադարձ փրոքսին կանգնած է նրանց ուղիներից միայն մեկի առջև։ Երեք պայման որոշում են, թե որ ճյուղում եք։
Երկու սերունդ, երկու միացման հաջորդականություն
Հին ձևավորումում, որը գործում է մինչև 2.8, ներմուծված ֆայլը կեղծ պրոֆիլ է։ OpenVPN Connect-ն օգտագործում է այն HTTPS-ով Access Server-ի վեբ API-ի դեմ նույնականացման համար, ստանում է ժամանակավոր օգտատիրոջը կցված պրոֆիլ և սեսիայի նշան, և միայն դրանից հետո է հաստատում VPN-ը։ Երկու տրանսպորտ աշխատում են հաջորդաբար, և առաջինը սովորական վեբ հարցում է։
2.9-ի հետ ներկայացված ձևաչափը չի կատարում այդ միացման նախապատրաստումը։ Սա բնիկ պրոֆիլ է, որը կարող են օգտագործել համատեղելի OpenVPN հաճախորդները, ոչ միայն OpenVPN Connect-ը։ Ներբեռնելը կամ URL-ով ներմուծելը դեռ կարող է ներառել HTTPS — դա հրապարակման քայլ է, ոչ թե յուրաքանչյուր միացման համար ժամանակավոր պրոֆիլի ստացում։
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
Թարմացումը պարտադիր չէ, որ վերագրի արդեն թողարկված պրոֆիլները, ուստի ընթացիկ սերվերի տարբերակը դեռ կարող է տարածել հին արտեֆակտը։ Սերվերի հավաքածուն ասում է, թե ինչ է հնարավոր, ոչ թե ինչ է ներմուծել այս օգտատերը։
Երեք պայման, որոնք ընտրում են ձեր ճյուղը
Առաջին պայմանը արտեֆակտի սերունդն է։ Հայցեք ֆայլը, տեսեք, թե ինչպես է այն արտադրվել, և նշեք այն հաճախորդի տարբերակը, որը ներմուծել է այն։ Եթե չեք կարող սերունդը որոշել ֆայլից, փորձնական հաշվի համար թողարկված նոր պրոֆիլը ձեզ կասի, թե սերվերն այսօր ինչ է արտադրում, և դա տարբեր տեղեկություն է, քան այն, ինչ ունի ձախողված օգտատերը։
Երկրորդն այն է, թե ձեր ճակատային մասը ինչ է իրականում ավարտում։ Յոթերորդ շերտի HTTP հակադարձ փրոքսին, որը հանում է TLS-ը, նույն օբյեկտը չէ, ինչ չորրորդ շերտի TCP փոխանցիչը, և UDP փոխանցիչը նույնպես չէ։ Access Server-ի սովորական դասավորությունը 443 պորտին ստիպում է OpenVPN TCP դեմոնին ճանաչել դիտարկիչի երթևեկությունը և հանձնել այն վեբ ծառայություններին, ուստի առջևում անկապ HTTPS ավարտիչ տեղադրելը չի պահպանում այդ դեմոնի արձանագրության մշակումը։ 443 թիվը կիսելը երկու ձևավորում հավասարազոր չի դարձնում։
Երրորդն այն է, թե որտեղ է ընկնում ձախողումը։ VPN-ից առաջ ձախողումը և կառավարման ուղու ձախողումը նման են թվում այն հաճախորդում, որն ասում է միայն "միանում է", բայց դրանք ապացույցներ են թողնում տարբեր տեղերում։ Եթե հին ձևաչափն է գործում, նախապատրաստումը թեկնածու է։ Եթե նոր ձևաչափն է գործում, դատարկ վեբ մուտքի մատյանը սպասելի է և ոչինչ չի ապացուցում ոչ մի ուղղությամբ։
Երբ արտեֆակտը հին է. նախապատրաստումը ձախողվում է առաջինը
Կարդացեք հաճախորդի փաստացի սխալը, ոչ թե նրա վերջնական վիճակը։ Հետաքրքիր դաշտերն են HTTPS սխալը, սերվերի այն ինքնությունը, որը հաճախորդը սպասում էր, այն նպատակակետը, ուր գնաց հարցումը, և արդյոք ավարտվեց վկայագրի ստուգումը։ Այնուհետև համեմատեք դրանք սերվերի կողմի վեբ ծառայության և փրոքսիի մատյանների հետ։
Դիտարկիչի հասնելը մուտքի էջին ապացույց չէ, որ այս հաճախորդի API նույնականացումը հաջողվել է։ Դրանք տարբեր հարցումներ են՝ տարբեր վկայագրի ակնկալիքներով և հաճախ տարբեր հոսթի անուններով։ Եթե պորտալը ճիշտ է սպասարկվում, և հաճախորդը դեռ ձախողվում է, տարաձայնությունը նախապատրաստման ուղու մեջ է, ոչ թե օգտատիրոջ գաղտնաբառի։
Չեք ստիպի համեմատությանը անցնել՝ անջատելով TLS ստուգումը կամ մեղմելով նույնականացման քաղաքականությունը։ Դա ախտորոշելի կոնֆիգուրացիայի անհամապատասխանությունը դարձնում է աշխատող, բայց չստուգված ուղի, և հենց այդ փոփոխությունն է ժամանակավոր փորձարկումը դարձնում մշտական անցք։ Access Server-ի միացման պրոֆիլների փաստաթղթերը նկարագրում են երկու սերունդները և ժամանակավոր պրոֆիլի հոսքը, և դա այն հղումն է, որը պետք է ստուգել նախքան փրոքսիին մեղադրելը։
Երբ արտեֆակտը նոր է. կարդացեք կառավարման ուղին
2.9 ոճի պրոֆիլի դեպքում հաճախորդը գնում է ուղիղ VPN-ի բնիկ վերջնակետին։ Ուսումնասիրեք պրոֆիլի վերջնակետերը, օգտագործվող տրանսպորտը և կառավարման ուղու սխալը։ Եթե հաճախորդը երբեք HTTP հարցում չի ուղարկում, դա համահունչ է ձևավորմանը և ախտանիշ չէ։
Այստեղ է, որ փրոքսիի հարցը նույնպես փոխում է ձևը։ HTTPS բեռնաթափումը չի կարող կոտրել միայն TCP հոսք, որը երբեք չի տեսնում, բայց այն դեռ կարող է կոտրել այն ներբեռնումը, որը հրապարակում է պրոֆիլը, և միայն TCP փոխանցիչը բացարձակապես UDP չի տանի։ Ստուգեք, թե պրոֆիլը որ տրանսպորտն է պահանջում, նախքան եզրակացնելը, որ ճակատային մասն անկարևոր է։
Մեկ հոսքի համար TLS փոխանցումը նեղ դասավորություն է։ Այն UDP փոխանցում չի ապահովում և չի վերարտադրում դեմոնի սեփական ծառայությունների փոխանցման վարքը 443-ում։ Եթե ձեր ճակատային մասը անում է դրանցից մեկը, ասեք որն է, որովհետև լուծումը տարբեր է։
Լուծումներ, որոնք մնում են նեղ
Ամենաքիչ միջամտող ստուգումը փորձնական հաշվի համար նոր աջակցվող պրոֆիլ ստեղծելն է և նույն նույնականացման պահանջներով նախատեսված բնիկ վերջնակետով միանալը։ Եթե դա աշխատում է, իսկ պահպանված հին պրոֆիլը՝ ոչ, դուք մեկ քայլով բաժանել եք արտեֆակտը սերվերից և փրոքսիից։
Օգտատիրոջը կցված պրոֆիլի տարածումը ամբողջությամբ հեռացնում է ժառանգված նախապատրաստման կախվածությունը, որովհետև չկա ժամանակավոր պրոֆիլի փոխանակում, որը կարող է ձախողվել։ Այն պետք է թողարկվի նախատեսված օգտատիրոջը, երբեք չպատճենվի ադմինիստրատորից, և փոխում է, թե ինչի է հաճախորդը լիազորված, ուստի վերաբերվեք դրան որպես քաղաքականության որոշում, ոչ թե շրջանցում։
Այնուհետև ուղղեք հրապարակման դասավորությունը, որպեսզի գոյություն ունենա յուրաքանչյուր պահանջվող ուղի՝ վեբ ուղին ներբեռնումների և պորտալի օգտագործման համար, և բնիկ VPN ուղին այն տրանսպորտի վրա, որը պրոֆիլները սպասում են։ Պահեք փրոքսիի աշխատանքը մեկ շերտում։ Աշխատող օգտատիրոջը կցված թունելն ապացուցում է, որ այդ ուղին աշխատում է, բայց չի ապացուցում, որ յուրաքանչյուր փրոքսի դասավորություն աջակցում է յուրաքանչյուր սերնդի, և հին նախապատրաստման ձախողումը չի դատապարտում նոր ձևաչափը։
- Որոշեք արտեֆակտի սերունդը նախքան փրոքսիին դիպչելը։
- Որոշեք, թե ձախողումը տեղի է ունենում թունելից առաջ, թե դրա ներսում։
- Հաստատեք, թե ճակատային մասն ինչ է ավարտում՝ HTTP, TCP հոսք, թե UDP։
- Փորձարկեք նոր թողարկված պրոֆիլը բնիկ վերջնակետի դեմ՝ անփոփոխ քաղաքականությամբ։