Ինչո՞ւ են PPTP-ն և L2TP/IPsec-ը կանգ առնում օգտանվի հարցումից առաջ
Օգտանվի հարցման բացակայությունը նշանակում է, որ PPP-ն երբեք չի սկսվել, ուստի անսարքությունը տրանսպորտում, բանալիների փոխանակման կամ թունելի կառուցման մեջ է։ Ստուգեք փուլերի հերթականությունը նախքան վերատեղադրումը։
Օգտանվի հարցման բացակայությունը ախտորոշիչ նվեր է. PPP-ն դեռ չի սկսվել, ուստի հաշիվը, գաղտնաբառը և տիրույթի քաղաքականությունը դեռ չեն հարցվել։ PPTP կամ L2TP/IPsec միացումում հաճախորդը հավատարմագրեր է պահանջում միայն այն բանից հետո, երբ թունելը գոյություն ունի, և սերվերը սկսել է PPP նստաշրջան։ Այն ամենը, ինչ կարող է ձախողվել այդ պահից առաջ, տրանսպորտն է, բանալիների փոխանակումը կամ թունելի կառուցումը, ինչը շատ ավելի փոքր մակերես է, քան «VPN-ը կոտրված է»։
Բացակա հարցումը սեղմում է անսարքությունը երեք փուլի
Գրի առեք վերջին փուլը, որը տեսանելիորեն հաջողվել է, որովհետև յուրաքանչյուրն ունի տարբեր տեր և տարբեր լուծում։ Երկու փուլ առաջ կանգնած ժամանակ հաշվի կարգավորումները գուշակելը այն ձևն է, որով մի կեսօր անհետանում է։
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Հարցում չստացած և ժամկետը լրացած հաճախորդը երբեք IPsec միացակցություն չի ստացել, ուստի անսարքությունը IKE-ում է կամ այն հարցում, թե արդյոք ձեր փաթեթները հասնում են դարպասին։ Այն հաճախորդը, որը հայտնում է հավատարմագրերի ստուգման մասին և հետո ընկնում է, ավելի հեռու է գնացել, քան հուշում է հաղորդագրությունը։ Հարցումից հետո մերժումը PPP նույնականացում է, և դրա տեղը հաշվի մասին հոդվածում է, ոչ այս մեկում։
Առաջին փուլ. արձանագրությունը, որը ֆայրվոլը լուռ գցում է
PPTP-ին անհրաժեշտ է TCP 1723 կառավարման ուղու համար և IP արձանագրություն 47 տվյալների ուղու համար, և երկուսը ճամփորդում են առանձին։ Շատ ցանցեր 1723-ը փոխանցում են և արձանագրություն 47-ը գցում, ինչը ստեղծում է թունել, որը բանակցում է և հետո ոչինչ չի տեղափոխում։ NAT անող երթուղիչին նույնպես պետք է GRE-աջակցվող անցում, և միայն IPv6-ով աշխատող մուտքի ուղին ոչ մի կարգավորմամբ չի կարող տեղափոխել PPTP։
L2TP-ն IPsec-ի վրա ծախսում է 500 պորտը IKE-ի համար և 4500 պորտը NAT-ի անցման համար, այնուհետև փաթաթում է հենց L2TP երթևեկությունը 1701-ի մեջ, մինչդեռ ESP-ն կրում է պաշտպանված բեռը, երբ միացակցությունը գոյություն ունի։ Թույլատրեք երկու կառավարման պորտերը, բայց ոչ ESP-ն, և դուք կստանաք հենց վերնագրի ախտանիշը. տեսանելի առաջընթաց, ապա մեռած հաճախորդ մինչև հավատարմագրերի ցանկացած երկխոսություն։ Հեռախոսի հոթսփոթից փորձարկելը էժան միջոց է հաճախորդի խնդիրը ուղու խնդրից անջատելու համար։
Երկրորդ փուլ. բանալի, որը բանալին չէ, առաջարկ, որը չի առաջարկվում
Չհամընկնող նախնական բաշխված բանալին արագ և լուռ ձախողվում է, և սովորական տարբերակը բանալին է, որը էկրանին ճիշտ է թվում, բայց կրում է փակցված տողադարձ կամ վերջում բացատ։ Linux հաճախորդում երկխոսությունը պարտադիր չէ, որ ճշմարտության աղբյուր լինի. NetworkManager-ի L2TP պլագինը գաղտնիքները պահում է /etc/ipsec.d/-ի տակ գտնվող ֆայլերում, և ավելի հին միացման ֆայլ, որը /etc/ipsec.secrets դեռ ներառում է, կօգտագործվի հենց նոր մուտքագրածի փոխարեն։ Պատճենեք այդ ֆայլը ապահով վայր, հանեք այն ներառման ուղուց, ապա ձեռքով կրկին մուտքագրեք բանալին։
Այս փուլի մյուս կեսը առաջարկն է։ Երկու ծայրերը պետք է համաձայնության գան նույն 1-ին փուլի ալգորիթմների հավաքածուի շուրջ — գաղտնագրում, ամբողջականություն և Diffie-Hellman խումբ — և 2-րդ փուլի համար համապատասխան ESP ձևափոխումների, այլապես միացակցությունն ընդհանրապես չի ձևավորվում։ Դարպասը, որն առաջարկում է միայն 3DES, SHA1 և MODP1024, կմերժի ավելի ուժեղ ալգորիթմների համար կարգավորված հաճախորդին, և նրա մատյանը նշում է մերժված ձևափոխումը։ Մատյանը նշում է անհամապատասխանությունը, եթե կարդաք այն՝ ծառայությունը կրկին վերագործարկելու փոխարեն։ Ֆորումի թեմայից ալգորիթմների տող պատճենելու փոխարեն հարցրեք դարպասին, թե որ ձևափոխումների շուրջ նա իրականում կբանակցի. իր հասցեին ուղղված ike-scan-ը վերադարձնում է այն ձևափոխումները, որոնց շուրջ նա կբանակցի։ Եթե միակ առաջարկը ձեր քաղաքականությանն այլևս չթույլատրված գաղտնագրությունն է, ուղղումը տեղին է դարպասի մոտ, ոչ թե հաճախորդի իջեցման։
Windows-ում բանալին և նույնականացման մեթոդը ապրում են VPN պրոֆիլում, և անհամապատասխանությունը երևում է հավատարմագրերի հարցումից առաջ, ոչ հետո։ Երբ ընդունողը Windows Server է, հաստատեք, որ հեռահար մուտքի դերը տեղադրված է, որ վկայականը համապատասխանում է այն անվանը, որին միանում են հաճախորդները, և որ ոչ մի պորտի զտիչ ավելի նեղ չէ վերը նշված արձանագրություններից։
Երրորդ փուլ. թունելը կա, և PPP-ն չի սկսվում
Երբ IKE-ն ավարտված է, և հարցումը դեռ չի հայտնվում, նայեք թունելի դեմոնին, ոչ թե ֆայրվոլին։ L2TP-ին պետք է մի բան, որ լսում է UDP 1701-ում — xl2tpd կամ kl2tpd Linux-ում, հեռահար մուտքի ծառայությունը Windows-ում — և տեղադրված, բայց կանգնեցված ծառայությունը հաճախորդի կողմից նույնն է երևում, ինչ գցված փաթեթը։ Ստուգեք լսողին նախքան ձեր արդեն իսկ հաստատած կանոնները նորից բացելը։ Այնուհետև PPP-ն պետք է բանակցի, և առաջին LCP փոխանակումը հենց այն տեղն է, որտեղ սովորաբար վայրէջք է կատարում լուռ ձախողումը։
Այս փուլի մի թակարդ ընդհանրապես ցանցային անսարքություն չէ. Windows-ը թույլատրում է տվյալ VPN տիպի միայն մեկ միացում միաժամանակ, ուստի երկրորդ փորձը վերադարձնում է 937 սխալը՝ «այս տիպի մեկ այլ միացում օգտագործման մեջ է»։ Դա տեղական կանոն է, և դրա շուրջը գնալու ուղին այլ սարքն է, այլ թունելի տիպը կամ արդեն իսկ գոյություն ունեցող միակ միացումը կիսելը։
Կարդացեք մատյանը փուլերի հերթականությամբ՝ գուշակելու փոխարեն
Կանգնեցրեք հաճախորդին, նորից գործարկեք այն և կարդացեք բաղադրիչները այն հերթականությամբ, որով նրանք գրում են մատյան։ Այսինքն նախ IPsec դեմոնը — strongSwan կամ Libreswan, և ipsec --version-ը ասում է, թե որն է — ապա L2TP դեմոնը, ապա pppd-ն։ Որ բաղադրիչն էլ վերջինը գրել է ձախողումից առաջ, այն նշում է քննության ենթակա փուլը, որովհետև հաջորդականության մեջ դրանից հետո եկող որևէ բան ընդհանրապես չի աշխատել։
Ստուգեք թարմ միացումով, ոչ պահված նստաշրջանով, որովհետև քեշից նորից միացող հաճախորդը կարող է բաց թողնել փոխանակման մասերը և վերարտադրել հնացած արդյունք։ Հաստատեք հասանելիությունը, բանալիների փոխանակումը, թունելը և PPP-ն մեկ առ մեկ, այդ հերթականությամբ։ Այն ժամանակ բացակա հարցումը դադարում է առեղծված լինելուց և դառնում է ցանկի երկրորդ տողը, որի վրա իրոք կարելի է աշխատել։ Այդ ցանկը նաև այն է, ինչ դուք հանձնում եք ցանցային թիմին, որից հակառակ դեպքում կպահանջվեր ստուգել ֆայրվոլը մի անսարքության համար, որն ապրում է չգործարկված դեմոնում։