L2TP, GRE თუ IPsec: რომელმა შრემ უნდა ატაროს სესია?
L2TP ატარებს PPP სესიებს, GRE — მარშრუტიზებულ პაკეტებს, IPsec იცავს შერჩეულ ტრაფიკს. მიანიჭეთ თითოეულ შრეს ერთი ამოცანა და შემდეგ თითოეული ცალკე გადაამოწმეთ.
ორი კითხვა ერევა ერთმანეთს ყოველ ჯერზე, როცა L2TP, GRE და IPsec ერთსა და იმავე საპროექტო ჩანაწერში ხვდება: რომელ სესიას ვატარებ და რომელი შრე იცავს მას? პირველი რომ შეცდეს, ყველაფერი ქვემოთ შიდად თანმიმდევრული რჩება, თუმცა არასწორ პრობლემას წყვეტს — მარშრუტიზებული გადაფარვა აშენებული იქ, სადაც მომხმარებლებს აკავშირება სჭირდებოდათ, ან აკავშირების კონცენტრატორი საიტ-საიტის კარიბჭის ნაცვლად. ქვემოთ მოცემული სამუშაო ფურცელი აიძულებს ამ გარჩევას მანამ, სანამ ვინმე მოწყობილობაში შევა. შეავსეთ ის რიგითობით და ყოველი ხაზი გახდება ის, რისი დამოუკიდებლად შემოწმებაც შეგიძლიათ.
დაიწყეთ სესიიდან და არა პროტოკოლების სიიდან
დისტანციური მომხმარებელი, რომელსაც PPP სესია უჭირავს, და ორ კარიბჭეს შორის მარშრუტიზებული გადაფარვა სხვადასხვა ქსელური ურთიერთობაა, მაშინაც კი, როცა ორივე საბოლოოდ IPsec-ში იფარება. პირველი ამთავრებს თითო მომხმარებლის კავშირს და მოითხოვს მისამართების განაწილებას, პიროვნების ან მოწყობილობის ავთენტიფიკაციას და პოლიტიკას, რომელიც ასახელებს, რომელ შიდა ქსელებამდე შეიძლება ამ მომხმარებელმა მიღწევა. მეორე გადასცემს პაკეტებს საიტებს შორის, სადაც არავინ აკავშირებს.
დაწერეთ ერთი წინადადება, რომელიც ასახელებს, რომელს აშენებთ ამ ორიდან, შემდეგ წაიკითხეთ ისე, თითქოს თქვენ ხართ ადამიანი, რომელმაც უნდა იმუშაოს მასზე. თუ წინადადებას სჭირდება სიტყვა „და“, თქვენ ორივეს აშენებთ და სამუშაო ფურცელს ორი სვეტი სჭირდება ერთი კომპრომისული სვეტის ნაცვლად, რომელიც თითოეულს ნახევრად ემსახურება. თუ ის ასახელებს მომხმარებელს, მაგრამ არა მისამართების აუზს, ან პრეფიქსს, მაგრამ არა გადაცემის პოლიტიკას, წინადადება ჯერ კიდევ არასრულია. ფორმულირება ბიუროკრატიულად ჟღერს, მაგრამ ეს ყველაზე იაფი ადგილია იმ პროექტის დასაჭერად, რომელიც სხვაგვარად დახმარების სამსახურის ბილეთით გამოვლინდება.
მიეცით ყოველ შრეს ზუსტად ერთი ამოცანა
L2TPv2 ატარებს PPP სესიებს თავის ორ ბოლო წერტილს შორის. PPP მართავს კავშირის მოლაპარაკებას და, როცა ის მოლაპარაკდება, მომხმარებლის ავთენტიფიკაციას; L2TP არანაირ დაშიფვრას არ ამატებს, ამიტომ შიშველი L2TP დემონი IPsec-ის უსაფრთხოების ურთიერთობის არცერთ ნაწილს არ ახორციელებს და ადგილი აქვს მხოლოდ იმ კავშირში, რომელსაც უკვე ენდობით.
GRE არის შეფუთვა ორ მისამართს შორის. ის ატარებს ქსელური შრის პაკეტებს ლოგიკურ გადაფარვაზე და თავისთავად არ სთავაზობს არც კონფიდენციალურობას და არც გაუმჟღავნებული პარტნიორის იდენტობას. ეს ნაკლი არ არის: სათაური შექმნილია მარტივად, რათა იაფი დარჩეს გადაცემის ტექნიკაზე დამუშავებისას. შედეგი ის არის, რომ GRE პასუხობს მხოლოდ კითხვას, როგორ გადავიტანო ეს პაკეტი ორ მისამართს შორის, და მეტს არაფერს, და ეს ზუსტად ის კითხვაა, რომელიც უნდა დაუსვათ მას.
რჩება IPsec, როგორც შრე, რომელიც ირჩევს ტრაფიკს, ავთენტიფიცირებს პარტნიორებს და შიფრავს იმას, რაც უთხრეს დაეცვა. რომელ ტრაფიკს იცავს ის, კონფიგურაციის გადაწყვეტილებაა, რომელიც უნდა შეესაბამებოდეს იმ შეფუთვას, რომელსაც ბოლო წერტილები რეალურად ქმნიან, რადგან GRE-ის გარე მისამართისთვის დაწერილი პოლიტიკა სხვაგვარად იქცევა, ვიდრე შიდა პრეფიქსებისთვის დაწერილი. GRE-ის სპეციფიკაცია თვალსაჩინოდ ჰყოფს ტვირთს, GRE-ის სათაურს და გარე მიწოდების პროტოკოლს, და თქვენს პოლიტიკას იგივე განცალკევება სჭირდება.
| Layer | Its one job | What it never does |
|---|---|---|
| PPP | Link negotiation, optional user authentication, address assignment | Protect traffic between gateways |
| L2TPv2 | Carry the PPP session between two endpoints | Encrypt or authenticate peers |
| GRE | Encapsulate network-layer packets between two addresses | Hide or authenticate the payload |
| IPsec | Authenticate peers and encrypt selected traffic | Carry 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 სესია იქ, სადაც პროექტი მას მოიცავს, და შიდა გადაცემა რეალურ დანიშნულების მისამართზე. ერთი მწვანე შუქი არ არის მტკიცებულება დანარჩენი სამისთვის, და ეს უფსკრული სწორედ ის მარცხია, რომელიც წარმოებაში ყველაზე დიდხანს რჩება — გვირაბი, რომელიც ჩართულია, დაშიფრულია და არაფერს გადასცემს, რადგან შიდა მარშრუტი არასოდეს დაემატა.
შეინახეთ შევსებული სამუშაო ფურცელი მოწყობილობის კონფიგურაციის გვერდით. ნებისმიერი სვეტი, რომელსაც ვერ შეავსებთ, შრეა დაუნიშნავი ამოცანით, და დაუნიშნავი ამოცანის მქონე შრე ჩვეულებრივ ის შრეა, რომელიც დასტაში არ უნდა იყოს.