vpnc ընդդեմ Check Point-ի կամ Nortel-ի՝ ինչու է կախվում

Ախտանիշը հեշտ է սխալ կարդալ՝ vpnc-ը սկսվում է, հարցնում է խմբի գաղտնաբառը, ապա մնում է բանակցության մի քայլում, մինչև հայտնում է, որ թիրախից պատասխան չկա։ Արդյունքում ոչ մի տեղ չի հիշատակվում դարպասի արտադրանքը, և հաշիվն աշխատում է զննարկիչից, ուստի ակնհայտ եզրակացությունը սխալ գաղտնաբառն է կամ արգելափակված պորտը։ Այս դեպքերի մեծ մասում դարպասը բոլորովին IPsec գործընկեր չէ, ուստի փոխանակումը երբեք չի հասնում հավատարմագրերի ստուգմանը։ Արժե ստուգել այս օրինաչափությունը, նախքան պրոֆիլում որևէ այլ բան փոխելը։

Նույնականացրեք արտադրանքը, նախքան պրոֆիլի մեկ այլ դաշտ խմբագրելը։

Ձախողումը նման է սխալ հավատարմագրերի

vpnc-ը սկսում է IKE ուղարկելով UDP 500-ին և, եթե առաջարկվում է NAT անցում, UDP 4500-ին։ Դարպասը, որը IPsec-ի փոխարեն ավարտում է SSL, չի պատասխանում ոչ մեկին, ուստի հաճախորդը կրկնում է փորձը և վերջում հանձնվում ընդհանուր սխալով։ Եթե նույն հաշիվն աշխատում է զննարկիչի պորտալով, որը բեռնում է փոքր օժանդակ հավելված, դա ուժեղ ակնարկ է, որ թունելը հիմնված է SSL-ի վրա, և հաճախորդը սխալ հարց է տալիս։

Այստեղ անհաջող փորձը ոչինչ չի ասում օգտատիրոջ հաշվի մասին, քանի որ դարպասին երբեք հավատարմագրեր չեն ներկայացվել։

Ստուգեք, թե որ արձանագրությունն է առաջարկում դարպասը

Երկու րոպե զննումը տարբերում է IPsec գործընկերոջը SSL պորտալից։ Գործարկեք դրանք նույն ցանցից, որը կօգտագործի հաճախորդը, և կարդացեք, թե որ պորտերն են պատասխանում, այլ ոչ թե որոնք են նշված փաստաթղթում։ Պահպանեք արդյունքը, քանի որ հենց այդ պորտերն են որոշում, թե որ հաճախորդին պետք է աջակցի դարպասի սեփականատերը։ Զննեք հաճախորդի ցանցից, այլ ոչ դարպասի կողքի հոսթից։

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Բաց 443-ը՝ մուտքի էջ վերահասցեավորմամբ, և լռությունը 500-ում ու 4500-ում մատնանշում են SSL VPN։ 443-ում տրամադրվող վկայականով բաց 500-ը և 4500-ը հուշում են IPsec դարպասի մասին, որը նաև վարում է վեբ ինտերֆեյս, և հենց այդ դեպքի համար է ստեղծվել vpnc-ը։

Check Point-ի SSL Network Extender-ը և Nortel-ի Aventail հաճախորդը երկուսն էլ երկրորդ կատեգորիայում են, և ոչ մեկը չի ընդունում IKEv1 խմբային գաղտնիք։

Ինչ կարող է և ինչ չի կարող արտահայտել vpnc-ի պրոֆիլը

Կափարիչի տակ vpnc-ը գործարկում է IKEv1 խմբային նախապես համօգտագործված բանալու դեմ, ապա ուղարկում առանձին օգտատիրոջ հավատարմագրերը XAuth-ի միջոցով։ Նրա կարգավորումների ֆայլում ամեն ինչ պատկանում է այդ փոխանակմանը՝ դարպաս, խմբի անուն, խմբային գաղտնիք, օգտատիրոջ անուն և օգտատիրոջ գաղտնաբառ։ Այդ դաշտերը նկարագրում են մեկ արձանագրություն, և դրանց ոչ մի համակցություն չի կարող ստիպել հաճախորդին խոսել մեկ ուրիշով։

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

Դարպասին համապատասխան հաճախորդի ընտրություն

Check Point դարպասի համար օգտագործեք այդ դարպասի թողարկման համար կառուցված SNX փաթեթը, որը մատակարարը հրապարակում է հեռահար մուտքի փաստաթղթերի հետ միասին։ Հին SNX կառուցվածքները հաճախ ձախողվում են ընթացիկ տարածումներում, քանի որ սպասում են 32-bit գրադարանների, որոնք այլևս տեղադրված չեն, և լքված փաթեթը կարկատելը սովորաբար ավելի վատ է, քան աջակցվող հաճախորդը աջակցվող հարթակում գործարկելը։

Aventail հաճախորդները վաղուց կորցրել են աջակցությունը։ Երբ նման դարպասը դեռ ծառայության մեջ է, իրատեսական ընտրանքներն են զննարկիչի պորտալը, եթե կազմակերպությունն այն միացնում է, կամ մատակարարի աջակցվող հաճախորդը աջակցվող օպերացիոն համակարգում։

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