Երկու հարց խճճվում են ամեն անգամ, երբ L2TP, GRE-ը և IPsec-ը հայտնվում են նույն նախագծային գրառման մեջ. ի՞նչ սեանս եմ ես տանում, և ո՞ր շերտն է պաշտպանում այն։ Առաջինը սխալ որոշելու դեպքում ամեն ինչ ներքևում մնում է ներքին առումով հետևողական, մինչդեռ լուծում է սխալ խնդիրը՝ երթուղվող վերածածկույթ, կառուցված այնտեղ, որտեղ օգտատերերին պետք էր ներհավաքում, կամ ներհավաքման կենտրոն՝ կայք-կայք դարպասի փոխարեն։ Ստորև ներկայացված աշխատաթերթը պարտադրում է այդ տարբերակումը նախքան որևէ մեկը մուտք գործի սարք։ Լրացրեք այն հերթականությամբ, և ամեն տող կդառնա մի բան, որը կարող եք ինքնուրույն ստուգել։

Սկսեք սեանսից, ոչ թե արձանագրությունների ցանկից

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

Գրեք մեկ նախադասություն, որը նշում է, թե երկուսից որն եք կառուցում, ապա կարդացեք այն այնպես, կարծես դուք եք այն մարդը, որը պետք է շահագործի այն։ Եթե նախադասությանը պետք է «և» բառը, դուք կառուցում եք երկուսն էլ, և աշխատաթերթին պետք են երկու սյունակ՝ մեկ փոխզիջումային սյունակի փոխարեն, որը կիսով չափ սպասարկում է յուրաքանչյուրին։ Եթե այն նշում է օգտատեր, բայց ոչ հասցեների լողավազան, կամ նախածանց, բայց ոչ փոխանցման քաղաքականություն, նախադասությունը դեռ թերի է։ Ձևակերպումը բյուրոկրատական է հնչում, բայց սա ամենաէժան տեղն է բռնելու այնպիսի նախագիծ, որը հակառակ դեպքում կբացահայտվի աջակցության ծառայության տոմսով։

Յուրաքանչյուր շերտին տվեք ուղիղ մեկ գործառույթ

L2TPv2-ը տանում է PPP սեանսներ իր երկու վերջնակետերի միջև։ PPP-ն վարում է կապի բանակցությունը և, երբ այն բանակցվում է, օգտատիրոջ նույնականացումը. L2TP-ն ոչ մի գաղտնագրում չի ավելացնում, ուստի մերկ L2TP դեյմոնը IPsec-ի անվտանգության հարաբերության ոչ մի մաս չի իրականացնում և տեղ ունի միայն այն կապի մեջ, որին դուք արդեն վստահում եք։

GRE-ն փաթաթում է երկու հասցեների միջև։ Այն տանում է ցանցային շերտի փաթեթները տրամաբանական վերածածկույթով և ինքնուրույն չի առաջարկում ոչ գաղտնիություն, ոչ էլ նույնականացված գործընկերոջ ինքնություն։ Դա թերություն չէ. վերնագիրը նախագծվել է պարզ, որպեսզի մնա էժան մշակելի փոխանցման ապարատի վրա։ Հետևանքն այն է, որ GRE-ն պատասխանում է միայն այն հարցին, թե ինչպես տեղափոխել այս փաթեթը երկու հասցեների միջև, և ոչ ավելին, և դա հենց այն հարցն է, որ պետք է տալ նրան։

Մնում է IPsec-ը՝ որպես շերտ, որը ընտրում է տրաֆիկը, նույնականացնում գործընկերներին և գաղտնագրում այն, ինչ իրեն ասվել է պաշտպանել։ Թե որ տրաֆիկն է այն պաշտպանում, կոնֆիգուրացիայի որոշում է, որը պետք է համապատասխանի այն փաթաթմանը, որը վերջնակետերն իրականում արտադրում են, քանի որ GRE-ի արտաքին հասցեի համար գրված քաղաքականությունն այլ կերպ է վարվում, քան ներքին նախածանցերի համար գրվածը։ GRE ճշգրտումը տեսանելիորեն առանձնացնում է բեռը, GRE վերնագիրը և արտաքին առաքման արձանագրությունը, և ձեր քաղաքականությանը նույն առանձնացումն է պետք։

LayerIts one jobWhat it never does
PPPLink negotiation, optional user authentication, address assignmentProtect traffic between gateways
L2TPv2Carry the PPP session between two endpointsEncrypt or authenticate peers
GREEncapsulate network-layer packets between two addressesHide or authenticate the payload
IPsecAuthenticate peers and encrypt selected trafficCarry a dial-in user session by itself

Գրեք փաթեթի ուղին մինչև կոնֆիգուրացիան

Վերցրեք մեկ փաթեթ և թվարկեք յուրաքանչյուր վերնագիր, որն ավելանում է, այն հերթականությամբ, որով ավելանում է՝ նշելով այն սարքը, որն ավելացնում է այն։ Ներհավաքման օգտատիրոջ համար դա սովորաբար PPP-ն է L2TP-ի մեջ, որն իր հերթին IPsec-ի մեջ է. կայքի վերածածկույթի համար դա ներքին IP փաթեթն է GRE-ի մեջ, որն իր հերթին IPsec-ի մեջ է։ Եթե երկու սարք ավելացնում են նույն վերնագիրը, դուք ունեք հանգույց կամ կրկնօրինակ թունել, և քաղաքականության ոչ մի խմբագրում դա չի շտկի։

Նույն ցանկը որոշում է MTU-ն, քանի որ օգտագործելի ներքին չափը չափված ուղու MTU-ն է՝ հանած ձեր հենց նշած վերնագրերը և ուրիշ ոչինչ։ Մի՛ պատճենեք թիվ ֆորումի գրառումից. գումարեք արտաքին IP-ի, UDP-ի և ESP-ի ծախսը, ապա GRE-ն կամ L2TP-ն, ապա PPP-ն, որտեղ կիրառելի է, և հանեք այն ուղու MTU-ից, որը դուք իրականում չափել եք։ Ախտանիշները, որոնք հայտնվում են միայն մեծ փոխանցումների ժամանակ, կամ սեանսները, որոնք հաստատվում են և հետո մահանում առաջին մեծ պատասխանի վրա, սովորաբար վերադառնում են նրան, որ այդ գումարումը կատարվել է գուշակությամբ։

Ստուգեք յուրաքանչյուր շերտը առանձին՝ դրսից ներս

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

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco-ի արկղում համարժեքը կախված է դերից, և ճշգրիտ շարահյուսությունը կախված է հարթակից ու թողարկումից. show crypto session IPsec գործընկերների համար, ինտերֆեյսի հաշվիչներ GRE կամ թունել ինտերֆեյսի համար, և VPDN կամ PPP ստուգում ներհավաքման դերի համար։ Հրամանների հավաքածուն, որը դադարեցնում է PPP-ն, ոչինչ չի ապացուցում GRE-ի աջակցության մասին, և աշխատող GRE ինտերֆեյսը ոչինչ չի ապացուցում PPP ծառայության մասին, ուստի ստուգեք այն դերը, որը դուք իրականում կարգավորել եք, այլ ոչ թե դիագրամի վրա եղածը։

Գրանցեք յուրաքանչյուր ելք աշխատաթերթի այն տողի կողքին, որին այն պատկանում է։ Խափանման պահին արված գրառումներն ավելի արժեքավոր են, քան հետագայում հիշողությամբ վերագծված տոպոլոգիան։

Կարգավորեք ապամոնտաժման հերթականությունը, ապա նորից ստուգեք

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

Վերակառուցումից հետո կրկնեք ընդունման չորս դիտարկումները մեկ առ մեկ. արտաքին հասանելիություն, հաստատված IPsec միավորում, հաստատված PPP սեանս այնտեղ, որտեղ նախագիծը ներառում է մեկը, և ներքին փոխանցում իրական նպատակակետ հասցեին։ Մեկ կանաչ լույսը ապացույց չէ մյուս երեքի համար, և այդ բացը հենց այն ձախողումն է, որն ամենաերկարն է ապրում արտադրությունում՝ թունել, որը միացած է, գաղտնագրված է և ոչինչ չի փոխանցում, քանի որ ներքին երթուղին երբեք չի ավելացվել։

Պահեք լրացված աշխատաթերթը սարքի կոնֆիգուրացիայի կողքին։ Ցանկացած սյունակ, որը չեք կարող լրացնել, շերտ է՝ առանց հանձնարարված գործառույթի, և առանց գործառույթի շերտը սովորաբար այն շերտն է, որը չպետք է լինի կույտում։

Առնչվող հոդվածներ