ASA-ի DHCP ռելեյը site-to-site VPN-ի վրայով. քայլ առ քայլ ուղեցույց

Ռելեյը աշխատում է երեք փուլով, և միայն միջինն է անցնում VPN-ով։ Հաճախորդը հեռարձակում է ճյուղի սեգմենտում, ASA-ն այդ հեռարձակումը վերածում է unicast հարցումի՝ ուղղված DHCP սերվերին, և սերվերը պատասխանում է ռելեյի հասցեին, այլ ոչ հաճախորդին։ Անցեք փուլերը հենց այդ հերթականությամբ, և «ռելեյը կոտրված է» դեպքերի մեծ մասը հանգում է բացակայող քաղաքականության կամ սխալ ընթերցված setroute տողի։

Առաջին փուլ. միացնել ռելեյը հաճախորդին ուղղված ինտերֆեյսի վրա

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

Նախքան որևէ բան փոխելը ստուգեք ընթացիկ կոնֆիգուրացիան՝ ո՞ր ինտերֆեյսն ունի ռելեյը միացված, ո՞ր սերվերի ձևն է առկա, և արդյոք setroute-ը կապված է հաճախորդի ինտերֆեյսին։ Եթե ASA-ն նաև DHCP սերվեր է աշխատեցնում այլ սեգմենտի համար, կանգ առեք և կարդացեք սահմանափակումների ցանկը. սերվերն ու ռելեյը չեն կարող միաժամանակ միացված լինել նույն սարքում։

Ռելեյն իր հաճախորդային հասցեն դնում է դարպասի հասցեի դաշտում։ Հենց այդ հասցեին է պատասխանելու սերվերը, ուստի այն պետք է հասանելի լինի հեռավոր վայրից թունելի միջով, ոչ միայն տեղային։

Երկրորդ փուլ. ASA-ի գեներացրած թրաֆիկը տանել թունելով

Սա այն քայլն է, որ մարդիկ բաց են թողնում։ Քաղաքականության վրա հիմնված site-to-site VPN-ը սովորաբար կառուցվում է ենթացանցերի միջև թրաֆիկի համար, իսկ ռելեյի հարցումը գեներացնում է հենց ASA-ն։ Եթե թունելի access list-ը և crypto map-ը համապատասխանում են միայն ճյուղի հոսթից սերվերի ենթացանց հոսքերին, ռելեյի փաթեթը կարող է երբեք չմտնել թունել։ Ստուգեք access list-ը երկու ուղղությամբ, ոչ միայն ճյուղից սերվեր տողը։

Համոզվեք, որ հետաքրքիր թրաֆիկը ծածկում է ASA-ի ռելեյի աղբյուրը և սերվերի հասցեն, և որ հետադարձ ուղղությունը նույնպես թույլատրված է։ VTI-ի վրա հիմնված ձևավորման դեպքում երթուղային որոշումն ավելի պարզ է, սակայն VTI-ի վրայով ռելեյի աջակցությունը եկել է որոշակի թողարկման մեջ. ASA-ի DHCP ուղեցույցը նշում է 9.14(1), ուստի ստուգեք պատկերը նախքան VTI-ի օրինակը ավելի հին սարքի վրա պատճենելը։

ASA-ից սերվեր ping-ը ինքնին քիչ բան է ապացուցում։ Այն կարող է հաջողվել այլ ուղով, այլ աղբյուրի հասցեով կամ այնպիսի քաղաքականության ներքո, որին ռելեյի փաթեթները չեն համապատասխանում։

Երրորդ փուլ. կարդալ պատասխանը և setroute ընտրանքը

RFC 2131-ը նշում է, որ երբ այդ դաշտը զրո չէ, սերվերն իր պատասխանն ուղարկում է giaddr-ի հասցեին։ Այսպիսով՝ հետադարձ ուղին պետք է երթուղվի ռելեյի հասցեին, և թունելի քաղաքականությունը պետք է թույլատրի սերվերից ռելեյ ուղղությունը։ Եթե հարցումն անցել է, բայց առաջարկը երբեք չի հասնում, նայելու տեղը հենց այստեղ է։

Ապա բաժանեք նման հնչող երկու բան։ setroute հիմնաբառը փոխում կամ ավելացնում է լռելյայն երթուղիչի ընտրանքը, որը ASA-ն տալիս է հաճախորդին։ Այն չի տեղադրում երթուղի ASA-ի վրա և չի ստեղծում VPN քաղաքականություն։ Հաճախորդը, որը հասցե է ստանում, բայց ոչինչ չի հասնում, հաճախ setroute-ի կամ scope-ի խնդիր ունի, ոչ թե թունելի։ Փորձարկեք ստատիկ դարպաս չունեցող հաճախորդով և տեսեք, թե որ լռելյայն երթուղիչն է հայտնվում առաջարկում։

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

Ինչ եմ ստուգում նախքան «ուղղված է» ասելը

Սկսեք հաճախորդից և որսացեք հեռարձակումը, ապա համոզվեք, որ ASA-ն այն վերահասցեավորել է իր սեփական հասցեով որպես giaddr։ Հեռավոր կողմում համոզվեք, որ սերվերը տեսել է այդ հարցումը և ընտրել ճյուղին համապատասխան scope։ Վերադառնալով ճյուղ՝ համոզվեք, որ հաճախորդն ընդունել է առաջարկը և հասնում է իր դարպասին։

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

Գրեք երեք փուլերը փոփոխությունների գրանցամատյանում՝ հաճախորդին ուղղված ինտերֆեյսը, ռելեյի թրաֆիկը ծածկող VPN քաղաքականությունը և սերվերի հետադարձ երթուղին դեպի giaddr։ Հենց այդ գրառումն է հաջորդ ճյուղի կառուցումը դարձնում կրկնելի աշխատանք՝ վրիպազերծման նստաշրջանի փոխարեն։ Այն նաև հուշում է հաջորդ ինժեներին, թե որ հրամանի արդյունքը հավաքել առաջինը։