Ինչու Android-ը միանում է տան IPsec VPN-ին, իսկ Windows-ը՝ ոչ
Հեռախոսը միանում է, նոութբուքը՝ ոչ, և գաղտնաբառը խնդիրը չէ: Երթուղիչն առաջարկում է IKEv1 XAUTH պրոֆիլ, որը Windows-ը երբեք չի տրամադրել:
Հեռախոսը առանց բողոքների մտնում է երթուղիչի VPN, մինչդեռ նույն Wi-Fi-ում գտնվող նոութբուքը չի կարողանում: Նույն մուտքային տվյալները, նույն սերվերը, նույն րոպեն: Տարբերությունը պրոտոկոլի աջակցությունն է, ոչ թե գաղտնաբառը. երթուղիչը ցուցադրում է պրոֆիլ, որը մի օպերացիոն համակարգ իրականացնում է, իսկ մյուսը երբեք չի ունեցել:
Նախ բացահայտեք պրոֆիլը, ապա համեմատեք այն այն բանի հետ, ինչ յուրաքանչյուր հաճախորդ իրականում խոսում է:
Մեկ ընտրացանկ, երեք պրոտոկոլ
Մեկ IPsec վերնագրի ներքո սպառողական որոնվածը կարող է թաքցնել երեք բոլորովին տարբեր թունելներ: Առաջինը IKEv1-ն է XAUTH-ով. ընդհանուր խմբային գաղտնիք, իսկ վրան՝ օգտանուն և գաղտնաբառ: Երկրորդը L2TP/IPsec-ն է, որտեղ PPP-ն աշխատում է ընդհանուր բանալիով պաշտպանված IPsec տրանսպորտի ներսում: Երրորդը IKEv2-ն է՝ նույնականացված վկայագրերով կամ EAP-ով:
Կարդացեք դաշտերը, ոչ թե պիտակը: Խմբային գաղտնիքն ու օգտվողների ցանկը նշանակում են IKEv1 XAUTH: Նախապես համօգտագործված բանալին ու PPP հաշիվը նշանակում են L2TP/IPsec: Սերվերի վկայագիրն առանց խմբային գաղտնիքի նշանակում է IKEv2:
Աջակցության ճեղքը հեռախոսի և նոութբուքի միջև
Android-ն ունի ներկառուցված IKEv1 XAUTH PSK հաճախորդ, և հենց դրա շնորհիվ է հեռախոսը հաջողության հասնում այն երթուղիչի հետ, որն այլ բան չի առաջարկում: Windows-ը՝ ոչ. նրա սեփական հաճախորդը կառավարում է L2TP/IPsec-ը և IKEv2-ը, և IKEv1 XAUTH տարբերակ չկա միացնելու համար: Գաղտնիքի կրկնակի մուտքը չի օգնի, որովհետև բացակայող մասը պրոտոկոլն է, ոչ թե մուտքային տվյալը:
Apple-ի կողմը շարժվող թիրախ է: macOS-ի և iOS-ի նոր թողարկումները հակվում են IKEv2-ին, Cisco ոճի հին պրոֆիլները պահպանվում են որոշ կառուցվածքներում, և թարմացումը կարող է հեռացնել կամ խստացնել այն, ինչ աշխատում էր անցյալ ամիս: Mac-ը, որը երեկ միանում էր, իսկ այսօր՝ ոչ, առանց երթուղիչի փոփոխության, սովորաբար սա է:
Երկու կարգավորում, որոնք կոտրում են այլապես ճիշտ պրոֆիլները
Synology-ի L2TP/IPsec էջը առաջարկում է Enable SHA2-256 compatible mode (96 bit) վանդակը: Apple-ի հաճախորդները iOS 14-ից և macOS Big Sur-ից սկսած մերժում են այդ կրճատված ռեժիմը, ուստի վանդակը նրանց համար պետք է անջատված լինի: Եթե այն միացված մնա, թունելը նույնականացվում է, ապա ընկնում, ինչը նման է վատ մուտքային տվյալների և այդպես չէ: Արտադրողը փաստաթղթավորում է անջատիչը, և օպերացիոն համակարգի թարմացումը սովորաբար այն պահն է, երբ սա սկսում է նշանակություն ունենալ:
Windows-ը վկայագրերը պահում է երկու առանձին պահոցում, և IKEv2-ը կարդում է միայն մեքենայի պահոցը: Ներմուծեք հաճախորդի վկայագիրը իր մասնավոր բանալիով համակարգչի հաշիվ. ձեր օգտվողի հաշվի տակ դրված վկայագիրը երևում է կառավարման վահանակում և երբեք չի հասնում IKEv2 ծառայությանը: EAP-TLS-ը միակ դեպքն է, երբ օգտվողի վկայագիրը օգտագործելի է, և ստորագրող CA-ն դեռ պետք է վստահելի լինի մեքենայի համար: Սա սխալ անելը երևում է որպես նույնականացման ձախողում, ոչ թե որպես բացակայող վկայագրի հարցում:
Երբ երթուղիչը մնում է այնպիսին, ինչպիսին կա
Երթուղիչը, որը խոսում է միայն XAUTH PSK-ով, թողնում է երեք ուղի. արտադրողի հաճախորդը, երրորդ կողմի հաճախորդ, որը դեռ իրականացնում է պրոֆիլը, կամ թունելի վերջնակետը տեղափոխել մի բանի, որը խոսում է IKEv2-ով: Օրինակ՝ AVM-ը հրապարակում է Windows հաճախորդի ծրագրաշար և արտահանված կարգավորման ֆայլ իր երթուղիչների համար: Այդ ուղին աջակցվում է, և նշանակում է արտադրողի գործիք տեղադրել յուրաքանչյուր նոութբուքի վրա:
Աջակցությունն ավելի կարևոր է, քան նրբագեղությունը, երբ նոութբուքերը ձերը չեն՝ վերակառուցելու համար:
Կշռեք նաև անվտանգության արժեքը: Մեկ խմբային գաղտնիք ծածկում է բոլոր օգտվողներին, ուստի ով ունի այն, կարող է կանգնել սերվերի փոխարեն և որսալ օգտանունն ու գաղտնաբառը, որոնք առաջարկում է հաճախորդը: Այնտեղ, որտեղ IKEv2-ը վկայագրերով հասանելի է, այդ տեղափոխումն ավելի արժեքավոր է, քան ցանկացած հաճախորդային շրջանցում:
Ախտորոշեք դրսից ներս
Նախ ստացեք մեկ աշխատող սեսիա հեռախոսից, որպեսզի սերվերի կողմն ապացուցված լինի նախքան նոութբուքի հայտնվելը: Ապա ներմուծեք երթուղիչի արտահանված պրոֆիլը առանց փոփոխության և կարդացեք հաճախորդի մատյանը՝ երթուղիչի կարգավիճակի էջի փոխարեն: Եթե մատյանը չի ցուցադրում ելքային առաջարկ, նոութբուքը երբեք չի հասել պատասխանողին: Եթե առաջարկները փոխանակվում են և ապա ձախողվում, տարաձայնությունը ալգորիթմների, ինքնության կամ մուտքային տվյալների մասին է:
Պահեք աշխատող հեռախոսի պրոֆիլը որպես հսկիչ: Երբ որոնվածի թարմացումից հետո կոտրվում է միայն նոութբուքը, սերվերի կողմն իրեն պահում է ինչպես առաջ: Երբ երկուսն էլ կոտրվում են, նայեք վկայագրին կամ լսողին՝ նախքան որևէ հաճախորդի դիպչելը: