კერძო 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 ნებართვა, გვირაბის მიბმა, შიდა მარშრუტი და აპლიკაციის პოლიტიკა. ეს ხუთი ჩანაწერი აჩვენებს, რომელი ფენა იქნება პასუხისმგებელი მომავალ უკმარისობაზე პორტის ეტიკეტზე დაყრდნობის გარეშე.

დაკავშირებული სტატიები