Ինչպես ստուգել՝ արդյոք VPN հաճախորդն իրոք աջակցում է SSTP-ին
Ներմուծման կոճակը և 443 պորտը ոչինչ չեն ապացուցում։ Ստուգեք նշված իրականացումը, պրոֆիլի ձևաչափը, սերտիֆիկատը և PPP նույնականացումը, ապա յուրաքանչյուր փուլ։
Ապրանքը VPN հաճախորդ անվանելը ոչինչ չի ասում այն մասին՝ արդյոք այն խոսում է SSTP-ով, իսկ հասցեում 443 պորտը ապացուցում է ավելի քիչ։ SSTP-ը TLS է աշխատեցնում TCP 443-ի վրա, ապա SSTP կառավարման փոխանակում, ապա PPP՝ հենց կապի համար, վերևում՝ սերտիֆիկատի ստուգում և PPP նույնականացման մեթոդ։ Հաճախորդը աջակցում է արձանագրությանը միայն այն դեպքում, երբ նշված իրականացումը՝ տեղադրված տարբերակում, լրացնում է այդ շերտերից յուրաքանչյուրը ձեր սերվերի պահանջներին համապատասխան։ Կատարեք ստորև բերված ստուգումները հերթականությամբ և կանգ առեք առաջին ձախողվածի վրա, որովհետև հենց այն արժե լուծել։
Համադրեք իրականացումը, տարբերակը և հարթակը
Սկսեք հարթակից, հավելվածից և տեղադրված կառուցվածքից, որովհետև մեկ արտադրողի անուն կարող է լինել երկու բոլորովին տարբեր իրականացումների վրա։ Ներկառուցված VPN տեսակները և երրորդ կողմի հաճախորդները նույն բանը չեն, և պլագինը կարող է ցույց տալ ադապտերի պիտակ, որը չի նկարագրում դրա տակ գտնվող արձանագրությունը։ Ընթացիկ թողարկման փաստաթղթերը չեն նկարագրում ձեր առջևի մեքենայում աշխատող կառուցվածքը։ Կարդացեք տարբերակին հատուկ էջը, ապա համեմատեք այն այն ամենի հետ, ինչ հաճախորդը հայտնում է իր մասին։
Windows-ում թունելի տեսակը գալիս է հարթակից, ոչ թե գրաֆիկական ինտերֆեյսից, ուստի հարցրեք հարթակին։ Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress ցույց է տալիս Sstp, երբ բնիկ հաճախորդը կփորձի արձանագրությունը, իսկ միացման տեսակների տեղեկագիրքը թվարկում է այն ներկառուցված թունելի տեսակների մեջ։ Linux-ում բնիկ SSTP հաճախորդ ընդհանրապես չկա, ուստի հարցը դառնում է՝ արդյոք sstp-client փաթեթից sstpc-ի նման առանձին իրականացումը տեղադրված և արդի է։
Պիտակից առաջ կարդացեք պրոֆիլի ձևաչափը
Պրոֆիլները փոխանակելի չեն, և ձեզ տրված ֆայլը սովորաբար լուծում է հարցը ավելի արագ, քան ցանկացած հատկությունների ցանկ։ OpenVPN-ի հրահանգները, WireGuard-ի բանալիները և SSTP-ի միացման կարգավորումները նկարագրում են երեք անկապ արձանագրություններ, և ոչ մի ներմուծման երկխոսություն մեկը չի վերածում մյուսի։ TCP 443 պորտի համօգտագործումը ոչինչ չի թարգմանում, քանի որ SSTP-ը, TLS-ի վրայի OpenVPN-ը և սովորական HTTPS ծառայությունը կարող են զբաղեցնել նույն պորտը և դրա վրա ոչինչ ընդհանուր չունենալ։
Եթե ֆայլը .ovpn է կամ WireGuard կարգավորում, պատասխանն արդեն սեղանին է՝ այդ հաճախորդից SSTP խոսել չեն պահանջում։ Այն միայն SSTP-ով աշխատող հաճախորդ ներմուծելը ձախողվում է պրոֆիլի փուլում՝ շատ առաջ արձանագրության ցանկացած բանակցությունից։
Ինչ TLS-ը չի ապացուցում տեղակայման մասին
Ավարտված TLS ձեռքսեղմումը ապացուցում է, որ սերվերն ունի սերտիֆիկատ, և ոչինչ չի ապացուցում այն մասին՝ արդյոք ձեր հաճախորդը վստահում է թողարկող շղթային կամ համապատասխանում է դրա ներսի անվանը։ Ստուգումը պետք է հաջողվի նախատեսված սերվերի դեմ՝ ներառյալ կազմակերպության կողմից վարվող ցանկացած մասնավոր CA, և սերտիֆիկատի սխալները բաց թողնել առաջարկող հաճախորդը հեռացրել է ստուգումը, այլ ոչ թե ստացել արձանագրության աջակցություն։ Շղթայի ստուգումը և անվան համընկնումը երկու առանձին թեստեր են, և մեկը հաղթահարող փաթեթը կարող է ձախողվել մյուսում։ Երկուսն էլ պատկանում են ընդունման չափանիշներին, ոչ թե խնդիրների լուծման հավելվածին։
Ապա հաստատեք PPP նույնականացման մեթոդը, որովհետև EAP-TLS-ով տեղակայումը պահանջում է հաճախորդ, որը կարող է սերտիֆիկատ ներկայացնել PPP-ի ներսում, մինչդեռ գաղտնաբառի վրա հիմնված մեթոդը պահանջում է այդ փոխանակման աջակցություն։ Սերվերի հասցեն և գաղտնաբառը չեն նկարագրում կազմակերպության իրական պահանջը, հատկապես երբ դրա առջև կա երկրորդ գործոն կամ սարքի ստուգում։ Հարցրեք, թե որ մեթոդն է սերվերը պարտադրում, նախքան ենթադրելը, որ հաճախորդը կարող է բավարարել այն։
Հետևեք սեանսին չորս փուլով
Դիտեք, թե ինչպես է միացումը հատում չորս սահման՝ TCP և TLS դեպի սերվեր, SSTP կառավարման փոխանակում, PPP բանակցություն, ապա ռեսուրսը, որն իրոք անհրաժեշտ է ձեզ։ Գրանցամատյանը, որը կանգ է առնում TLS-ից հետո, նկարագրում է այլ խափանում, քան PPP-ի ներսում կանգ առնողը, և երկուսը տանում են տարբեր պատասխանատուների։ Դիտարկիչում հոսթի վեբ էջի բեռնումը ապացուցում է միայն, որ ինչ-որ բան պատասխանել է 443-ին, ինչը այս ոլորտում ամենատարածված կեղծ դրական արդյունքն է։ Եթե այդ էջը բեռնվում է, բայց հաճախորդը դեռ ձախողվում է, խնդիրը TLS-ից վերև է և վեբ սերվերը կասկածյալ չէ։
Ավարտեք իրական մասնավոր ռեսուրսով և անվան որոնմամբ, որովհետև հաստատված և ոչինչ չփոխանցող սեանսը կարգավիճակի պատուհանների մեծ մասում նույն տեսքն ունի, ինչ աշխատողը։ Ձեզ անհրաժեշտ ռեսուրսին ուղղված մեկ հաջող հարցումը լուծում է մի հարց, որը պատկերակը չի կարող։
Երբ աջակցությունը բացակայում է, փոխեք պլանը
Եթե հաճախորդը չի կարող խոսել SSTP-ով, ձեռք բերեք հաստատված այլընտրանք կամ սերվերի տիրոջից պահանջեք արձանագրություն, որը երկու կողմերն էլ աջակցում են։ Անհայտ ընտրանքների ջնջումը մինչև ներմուծման հաջողվելը ստեղծում է պրոֆիլ, որը ոչ մի տեղ չի միանում, ինչը դանդաղ ճանապարհ է դեպի նույն փակուղին։ Անհայտ աղբյուրից տեղադրիչը, որը գովազդում է համընդհանուր համատեղելիություն, մեքենային ավելացնում է չհաստատված վստահության ուղի և հաճախ փոխարինում է հարթակի հաճախորդին մի բանով, որը կազմակերպությունը չի կարող թարմացնել։ Ոչ մի քայլ լուծում չէ, և երկուսն էլ ավելի դժվար է հետ շրջել, քան սկզբնական խնդիրը։
Համատեղելիության հարցը դիտարկեք առանձին արտադրողականությունից և վերջնակետի ընտրությունից, որովհետև մոտակա սերվերն անօգուտ է, երբ հաճախորդը չի կարող խոսել դրա արձանագրությամբ։ Ուշացման կարգավորումը չի վերականգնում երբեք չավարտվող փուլը։