IPsec մասնավոր WAN-ի վրա. SRX քաղաքականության սահմանները, որոնք պետք է ստուգել

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

Նախ գրանցեք արտաքին IKE ուղին

Քաղաքականությանը դիպչելուց առաջ գրեք չորս արժեք՝ զուգընկերոջ հասցեն, IKE ընդունող տեղական ինտերֆեյսը, զուգընկերոջը հասնող երթուղայնության համատեքստը և այդ ինտերֆեյսն ընտրող երթուղին։ IKE փաթեթները հասցեագրված են հենց SRX-ին, ուստի դրանց անհրաժեշտ է host-inbound թույլտվություն ընդունող գոտում, ոչ թե փոխանցվող երթևեկության քաղաքականություն։ Մասնավոր WAN հասցեն չի վերացնում այդ պահանջը, քանի որ փաթեթը դեռ ավարտվում է սարքում։

Ստուգեք տեղադրված վիճակը այս հրամանով՝ show security ike sa և կոնֆիգուրացիան այս հրամանով՝ show configuration security ike։ Առաջինը ցույց է տալիս՝ արդյոք գոյություն ունի 1-ին փուլը, երկրորդը՝ ինչ է կարծում սարքը, որ պետք է անի։

Կապակցեք թունելի ինտերֆեյսը ճիշտ քաղաքականությանը

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

Կարդացեք իրական կապակցումները, ոչ թե հին դիագրամ՝ show configuration security ipsec vpn ինտերֆեյսին կապակցելու կարգավորման համար և show configuration security policies թունելի գոտուն հղվող կանոնների համար։

Եթե պաշտպանված երթուղին այլ տեղ է մատնանշում, թունելը կարող է վերևում լինել, մինչդեռ երթևեկությունը երբեք չի մտնում այնտեղ։ Սա երթուղայնության խնդիր է IPsec-ի զգեստով։

Պահեք զուգընկերոջ երթուղին underlay-ում

Արտաքին զուգընկերոջ երթուղին պետք է լուծվի underlay-ի միջոցով, ոչ ռեկուրսիվ՝ իր ստեղծած թունելի միջոցով։ Եթե զուգընկերոջ երթուղին մատնանշում է թունելի ինտերֆեյսը, IKE փաթեթները հետապնդում են իրենց թունելը, և 1-ին փուլը երբեք չի ավարտվում։ Պաշտպանված երթևեկության պատասխան ուղին կարիք ունի իր ճիշտ երթուղուն և քաղաքականությանը, և սովորաբար դա հենց բացակայող կեսն է, երբ մի ուղղություն աշխատում է։ Կարդացեք զուգընկերոջ հասցեի երթուղային աղյուսակի գրառումը և հաստատեք, որ ելքային ինտերֆեյսը WAN ինտերֆեյսն է։

Ստուգեք այն այս հրամանով՝ show route 198.51.100.10, տեղադրելով իրական զուգընկերոջ հասցեն, և հաստատեք, որ հաջորդ թռիչքը թունելի ինտերֆեյս չէ։

Ստուգեք կառավարումը և ծառայությունը հերթականությամբ

Աշխատեք դեպի վեր՝ 1-ին փուլի վիճակը, 2-րդ փուլի վիճակը, ապա իրական հավելվածային հոսք։ show security ipsec sa թվարկում է անվտանգության ասոցիացիաները, և show security flow session destination-prefix 10.60.0.0/16 ցույց է տալիս՝ արդյոք պաշտպանված ցանցի համար ստեղծվում են փոխանցվող սեանսներ։

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

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