VPN-ի որ փուլն է ձախողվել՝ IPsec, L2TP կառավարում, թե PPP նույնականացում
Գտեք վերջին հաջողված փուլը և ուղղեք միայն այդ շերտը՝ IPsec, L2TP կառավարման ալիքը, PPP նույնականացումը կամ հասցեի տրամադրումը։
Փոխեցիք գաղտնաբառը, և ոչինչ չշարժվեց, որովհետև խափանումը երբեք PPP-ում չէր։ L2TP/IPsec-ը հաղորդում է մեկ կապի սխալ հինգ բոլորովին տարբեր հանձնումների համար, և յուրաքանչյուր հանձնում ունի իր վերանորոգումը։ Աշխատեք հակառակ ուղղությամբ՝ գտեք վերջին հաջողված փուլը և փոխեք միայն այն, ինչ գալիս է դրանից հետո։ Ստորև բերված հերթականությունը նաև որոշում է, թե որ ապացույցներն առաջինը հավաքեք։
Պատասխանեք չորս հարցի հերթականությամբ
Ստիպեք նոր փորձ, քանի որ որոշ հաճախորդներ ցույց են տալիս նախորդ սխալը, մինչև պրոֆիլը անջատվի և նորից միանա։ Ապա պատասխանեք սրան՝ կար IPsec անվտանգության ասոցիացիա, հայտնվե՞ցին L2TP կառավարման կապ և զանգ, PPP-ն հասավ նույնականացման վճռի, և IPCP-ն հաճախորդին հասցե տվե՞ց։ Առաջին ոչ-ը այն փուլն է, որը ուղղում եք։ Դրանից հետո ամեն ինչ չստուգված է, ուստի մերժված օգտանունը ոչինչ չի ապացուցում, երբ ասոցիացիա երբեք չի եղել։
Համեմատելուց առաջ համաժամեցրեք ժամացույցները երկու ծայրերում։ Նորից փորձը, որը մաքրեց IPsec-ը և ձախողվեց PPP-ում, երևում է որպես մեկ խափանում, երբ հաճախորդը ցույց է տալիս միայն վերջին հաղորդագրությունը, իսկ սերվերի մատյանը դեռ պահում է նախորդ փորձը։ Կարդացեք ժամային նշանի համաձայն, ոչ ամենաբարձր ձայնի տողով։
Երբ ունեք միայն օգտվողի էկրանի պատկերը, հենվեք ամենաէժան բաժանման վրա՝ սխալ նախապես համօգտագործված բանալին և երբեք չպատասխանող xl2tpd-ն նույն տեքստն են ստեղծում Windows-ի երկխոսության մեջ, սակայն մեկին անհրաժեշտ է երկու ծայրերում փոխված գաղտնիք, իսկ մյուսին՝ սերվերի վրա գործարկված դեմոն կամ firewall-ի կանոն։ Մեջտեղի սարքը չի կարող գցել ներքին 1701-ը այն բանից հետո, երբ transport ռեժիմի IPsec-ը փաթաթել է այն, ուստի մի փնտրեք ուղու զտիչ, որը չկա։
Ինչ է իրականում պատկանում յուրաքանչյուր շերտին
IPsec-ը պաշտպանում է փաթեթները երկու գործընկերների միջև, L2TP-ն PPP սեսիան տանում է այդ պաշտպանված ուղու ներսում, դրա համար էլ RFC 3193-ը սահմանում է transport ռեժիմ՝ սեփական թունելի փոխարեն։ Հաճախորդի պիտակը ասում է L2TP, ուստի թունելն ու մուտքը մեկ մեխանիզմ են թվում։ Այդպես չէ՝ L2TP կառավարման կապը նույնականացնում է թունելի ծայրերը այնտեղ, որտեղ տեղակայումը միացնում է այն, իսկ PPP-ն առանձին նույնականացնում է օգտվողին CHAP-ով, PAP-ով կամ MS-CHAPv2-ով՝ սերվերի քաղաքականության համաձայն։
Այս բաժանումը բացատրում է այն երկու գաղտնիքները, որ մարդիկ անընդհատ շփոթում են։ Նախապես համօգտագործված բանալին նույնականացնում է IPsec գործընկերներին։ Օգտանունը և գաղտնաբառը նույնականացնում են օգտվողին PPP-ի համար։ Windows-ի համօգտագործված գաղտնիքը վկայագրերով նույնականացվող պրոֆիլում նորից մուտքագրելը ոչինչ չի փոխում ձախողվող փուլում, իսկ PPP գաղտնաբառը խմբագրելը չի կարող տալ բացակայող պաշտպանված ալիք։ Նույն զսպվածությունը վերաբերում է նաև ինքնության ստուգմանը՝ թունել ստանալու համար մի անջատեք գործընկերոջ ինքնությունը կամ վկայագրի վավերացումը, քանի որ այդ դեպքում միանում է ուղին, ոչ գործընկերը։
Նույնականացումը նույնպես PPP-ի վերջը չէ։ Օգտվողի ընդունումից հետո IPCP-ն բանակցում է հաճախորդի հասցեն և DNS ու WINS ընտրանքները, որոնք սերվերը պատրաստ է տալ։ Հաճախորդը կարող է անցնել CHAP-ը կամ MS-CHAPv2-ը և մնալ առանց հասցեի, ինչը PPP-ի ներսում խափանում է, ոչ երթուղավորման խնդիր։ IPsec-ից զուրկ սովորական L2TP-ն մնում է վավեր և անպաշտպան, ուստի հաջող կապը երբեք չի ապացուցում, որ երթևեկությունը պաշտպանված է. ստուգեք, ինչ է պահանջում սերվերը, ոչ հաճախորդի պիտակը։
Որոշեք առաջին բացակայող փուլից
Կարդացեք աղյուսակը առաջին բացակայող կետով՝ ձախից աջ։ Աջ սյունակը այդ պահին արժեքավոր միակ աշխատանքն է, նրանից ձախ ամեն ինչ արդեն ապացուցված է, և այն նորից ստուգելը այրում է ընդհատման պատուհանը՝ առանց տեղեկություն ավելացնելու։
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Երեք տող արժանի են նախազգուշացման։ 1701 տողը այն տեղն է, որտեղ NAT-ի հետևում գտնվող Windows հաճախորդները սովորաբար վայրէջք են կատարում՝ ասոցիացիան ավարտվում է, ապա ոչինչ չի հասնում, և պատճառը ինկապսուլյացիան է, ոչ վատ գաղտնաբառը։ IPCP տողը այն է, որը սխալ ընթերցվում է որպես երթուղու խնդիր, քանի որ Windows-ը բացակայող հասցեն փաթաթում է 720 սխալի մեջ, իսկ սկուտեղի պատկերակը միայն ասում է, որ կապը ձախողվեց. այդ խափանումը գտնվում է նույնականացումից հետո և երթուղավորումից առաջ։ Վերջին տողը բոլորովին IPsec խափանում չէ, թեև պատկերակը ասում է անջատված։
Հրամաններ, որոնք բաժանում են շերտերը
strongSwan-ով Linux սերվերի վրա swanctl --list-sas-ը թվարկում է հաստատված ասոցիացիաները գործընկերոջ ինքնությամբ, իսկ ipsec statusall-ը ընդգրկում է ավելի հին strongSwan և libreswan հոսթեր։ Դրա տակ ip xfrm state-ը ցույց է տալիս միջուկի իրական ասոցիացիաները, մինչդեռ ss -lunp | grep 1701-ը ապացուցում է, թե որտեղ է կապված xl2tpd-ն։ Գործարկեք xl2tpd -D-ը առաջին պլանում՝ կառավարման կապերն ու զանգերը տեսնելու համար, և միացրեք pppd-ի վրիպազերծումը /etc/ppp/options.xl2tpd-ում՝ առաջարկվող մեթոդն ու պատասխանը տեսնելու համար։
Երբ մատյանները ցույց են տալիս հաջող նույնականացում, հաջորդ հարցն այն է՝ ավարտվե՞ց IPCP-ն։ Ստուգեք՝ արդյոք /etc/xl2tpd/xl2tpd.conf-ի [lns default] բաժնի ip range-ն դեռ ունի ազատ հասցեներ, և արդյոք /etc/ppp/options.xl2tpd-ը իսկապես կրում է ms-dns և ms-wins, եթե հաճախորդը սպասում է դրանց։ Սպառված լողավազանը և բացակայող DNS ընտրանքը լարի վրա տարբեր են երևում՝ առաջինը հաճախորդին թողնում է առանց հասցեի և 720-ով, երկրորդը տալիս է հասցե, բայց ոչ լուծիչ, ուստի անունները ձախողվում են, մինչդեռ հում հասցեներին ping-ը աշխատում է։ Ոչ մեկը չի վերանորոգվում գաղտնաբառը նորից մուտքագրելով։
Հաճախորդում NetworkManager-ի L2TP հավելվածը pppd-ի զրույցը գրում է մատյանում, ուստի journalctl -u NetworkManager -b-ը սովորաբար բաժանում է թունելը վերև է, նույնականացումը մերժված է վիճակը ընդհանրապես թունել չկա վիճակից։ Windows-ում Get-VpnConnection-ը հաղորդում է պրոֆիլի իրական նույնականացման կարգավորումները, և Event Viewer-ի Application բաժնի RasClient իրադարձությունները նշում են ձախողված բաղադրիչը։ Երբ երկխոսությունը չափազանց մշուշոտ է, միացրեք netsh ras set tracing * enable-ը։
Գրանցումները պահանջում են մեկ զգուշություն։ Transport ռեժիմի IPsec-ի դեպքում ներքին UDP 1701-ը գաղտնագրված է, ուստի արտաքին ինտերֆեյսի գրանցումը ցույց է տալիս ESP կամ NAT-T-ի դեպքում՝ UDP 4500, և բոլորովին L2TP չի ցույց տալիս։ 1701-ի բացակայությունը գրանցման մեջ սպասելի է և արգելափակված պորտի ապացույց չէ. հետևեք՝ արդյոք ESP կամ 4500 հաշվիչները շարժվում են։
NAT, MTU և երթուղիներ՝ որտեղ կույտը մոլորեցնում է ձեզ
NAT-ը կոտրում է ենթադրությունները նախքան ինչ-որ բան նույնականացվելը։ ESP-ն իր սեփական IP արձանագրությունն է, ուստի թարգմանող սարքը դեն է նետում այն, եթե գործընկերները չեն ինկապսուլացնում. հենց դա է ապահովում UDP 4500-ը։ Windows սերվերում, որն ինքն է կանգնած տնային երթուղիչի կամ ամպային NAT դարպասի հետևում, IPsec փուլը ձախողվում է 789 սխալով, մինչև PolicyAgent բանալու տակ AssumeUDPEncapsulationContextOnSendRule-ը դրվի 2-ի և մեքենան վերագործարկվի, և խափանումը մնում է անտարբերելի փակ պորտից։ NAT-ի հետևում գտնվող հաճախորդներն ավելի հեշտ են՝ սերվերի վրա հանրային հասցեի դեպքում UDP 4500-ի վրա NAT-T-ն է նրանց տանում, և այդ արժեքը ներգրավված չէ։
Երբ PPP-ն վերև է, սև փոսով MTU-ն ընդօրինակում է մեռած թունել՝ փոքր փաթեթներն անցնում են, TLS ձեռքսեղմումը կամ էջի բեռնումը կախվում է, և հաճախորդը կարող է դեռ ցույց տալ միացված։ Սերվերը մեղադրելուց առաջ իջեցրեք ինտերֆեյսի MTU-ն կամ սեղմեք MSS-ը դարպասում։ Բաժանված թունելի երթուղավորումը մյուս խաբեբան է. սխալ դիմակով ուղարկված ենթացանցը թունելը թողնում է առողջ, իսկ մեկ հավելվածը՝ անհասանելի։ Մասնավոր հոսթի անունն ավելացնում է իր քայլը՝ եթե հարցումը դուրս է գալիս տեղական լուծիչով, անունը չի լուծվում նախքան որևէ երթուղու ստուգումը։
Ստուգաթերթ նախքան հավատարմագրերին դիպչելը
Անցեք ցանկը հերթականությամբ և կանգ առեք առաջին ձախողվող կետում։ Յուրաքանչյուր քայլ էժան է, և յուրաքանչյուրը բացառում է ուղղումների մի ամբողջ դաս։
- Հաստատեք, որ ասոցիացիան կա երկու ծայրերում՝ համադրված գործընկերոջ ինքնությամբ, ոչ միացված պիտակով։
- Հաստատեք, որ UDP 1701-ը հասնում է xl2tpd-ին. զանգ չունեցող ասոցիացիան ձեր խափանումն է։
- Կարդացեք PPP-ի վճիռը և, եթե նույնականացրել է, IPCP-ի արդյունքը, նախքան ենթադրելը, որ գաղտնաբառը սխալ է։
- Միայն հիմա նորից մուտքագրեք հավատարմագրերը սերվերի սպասած ձևաչափով, քանի որ դոմենի նախածանցը փոխում է հաշիվը։
- Եթե դեռ ձախողվում է, գրանցեք երկու ծայրերը հավասարեցված ժամային նշաններով և համեմատեք փուլ առ փուլ։
Երկրորդ քայլում կանգ առնելը նշանակում է ուղու կամ ինկապսուլյացիայի խնդիր, և գաղտնաբառի ոչ մի ուղղում այն չի շարժի։ Երրորդ քայլում կանգ առնելը նշանակում է, որ մատյանն արդեն անվանում է ուղղելիք մեթոդը կամ հասցեների լողավազանը։ Ամեն դեպքում հաջորդ փոփոխությունն այն է, որը կարող եք հիմնավորել, և դադարում եք պտտվել այն կարգավորումներում, որոնք երբեք ներգրավված չեն եղել։