PPP peer მისამართი თუ VPN საბოლოო წერტილი: რომელი იწერება via-ში

PPP ინტერფეისზე ერთი ხაზი წყვეტს VPN ყუთზე მარშრუტიზაციის კამათის უმეტეს ნაწილს: შიდა მისამართი და მის გვერდით დაბეჭდილი peer. წაიკითხეთ ეს წყვილი როგორც პაწაწინა ქვექსელი და თქვენ ეძებთ ჭიშკარს, რომელიც არ არსებობს. წაიკითხეთ ის როგორც ერთი ბმულის ორი ბოლო და შემდეგი ნახტომი აშკარა გახდება. აქ შედარება ამ ორ წაკითხვას შორისაა, რადგან ყოველი შემდგომ აშენებული ცხრილი მემკვიდრეობით იღებს არჩეულს. გარე VPN საბოლოო წერტილზე არც ერთი მათგანი არაფერს წყვეტს.

ერთი ინტერფეისის ხაზის ორი წაკითხვა

აიღეთ სესია, სადაც ინტერფეისი აცხადებს inet 10.64.3.9 peer 10.64.3.1/32. ქვექსელური წაკითხვა 10.64.3.9-ს ეპყრობა როგორც მარტოხელა ჰოსტს /32 კუნძულზე და შემდეგ ეძებს მარშრუტიზატორს, რომ მის გარეთ რამეს მიაღწიოს. ვინაიდან ბმულზე ერთადერთი სხვა მისამართი peer-ია, ეს წაკითხვა საბოლოოდ თავად 10.64.3.9-ს სთავაზობს ჭიშკრად, რაც წრიულია.

საბოლოო წერტილის წაკითხვა დოკუმენტირებულია. წერტილიდან წერტილამდე ინტერფეისზე peer ასახელებს ამ ერთი ბმულის შორეულ ბოლოს, ამიტომ 10.64.3.1 გამოსადეგი შემდეგი ნახტომია, ხოლო 10.64.3.9 ყოველთვის მხოლოდ წყაროს მისამართია.

ეს განსხვავება განსაზღვრავს, რა შეიძლება იყოს via-ში. იქ ლოკალური მისამართის ჩაწერა ქმნის მარშრუტს, რომელსაც ბირთვი მეზობელთან ვერ დააკავშირებს, ამიტომ ჩანაწერი ან ვერ გაივლის ვალიდაციას, ან ყლაპავს ტრაფიკს სიაში სრულიად ჯანმრთელად გამოიყურება. Peer მუშაობს, რადგან ის ბმულზე ნამდვილი დანიშნულებაა. ორივე წაკითხვა თანხმდება გარე VPN საბოლოო წერტილზე, რომელიც სრულიად ცალკე იდენტობაა: მასზე აღწევენ underlay-ის გავლით, და არა იმ გვირაბის გავლით, რომელსაც ის ამთავრებს.

რა უკვე დააყენა სესიამ

სანამ საკუთარ ცხრილს დაწერთ, დაბეჭდეთ ის, რაც ბმულთან ერთად მოვიდა. მხარდაჭერილი PPP ინტეგრაცია ჩვეულებრივ სესიის დაყენებისას აყენებს მოწყობილობის მარშრუტს და peer-ის მარშრუტს, და ეს ორი ჩანაწერი უკვე კოდირებს სწორ წაკითხვას.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9-ის მსგავსი მოწყობილობის მარშრუტი ჭიშკარს არ ატარებს, რადგან თავად ინტერფეისია გზა. მარშრუტი, რომელიც peer-ს ასახელებს via-ით, სხვა ობიექტია სხვა სიცოცხლის ხანგრძლივობით, და ის ქრება, როცა სესია ვარდება. ორი ფორმიდან ერთის მუდმივ ცხრილში კოპირება იმის შემოწმების გარეშე, თუ როგორ ხდება მისი ხელახლა დაყენება, ჩვეულებრივი მიზეზია იმისა, რომ მუშა გვირაბი ხელახალი დაკავშირების შემდეგ კარგავს მარშრუტს.

შეადარეთ ორი სია და ნუ დაეყრდნობით მეხსიერებას. თუ peer-ის მარშრუტი არსებობს main-ში, მაგრამ თქვენი დამატებითი ცხრილი ცარიელია, თქვენ ისწავლეთ რაღაც, რაც მისამართის ხაზმა არასდროს გითხრათ.

წესი და ცხრილი ცალკე გადაწყვეტილებებია

ცხრილის არჩევა და მისი შევსება დამოუკიდებელი ნაბიჯებია და შედარება აქ მნიშვნელოვანია, რადგან გამართვის დროს ეს ორი ხშირად ერევა ერთმანეთს. წესი, რომელიც მონიშნულ ტრაფიკს 100 ცხრილში აგზავნის, არაფერს აკეთებს, თუ 100 ცხრილში შესაბამისი მარშრუტი არ არის, ხოლო კარგად შევსებული ცხრილი მიუწვდომელია, თუ მასზე არც ერთი წესი არ მიუთითებს.

ნაგულისხმევი მარშრუტის ნახევარი ნაგულისხმევი მარშრუტი არ არის. ერთი 0.0.0.0/1 ფარავს IPv4 სივრცის ქვედა ნახევარს, ამიტომ ყველაფრის დაჭერის განზრახვის მქონე პოლიტიკას სჭირდება შესაბამისი 128.0.0.0/1 ან ნამდვილი default. მუშა კონფიგურაციის წაკითხვა და ორი ნახევრიდან ერთის კოპირება ის გზაა, რომლითაც ადამიანები აღმოჩნდებიან მარშრუტიზაციის ციკლში, რომელიც ირღვევა მხოლოდ გარკვეულ დანიშნულებებზე.

დატოვეთ განზრახ გამონაკლისები იმ მისამართებისთვის, რომლებიც LAN-ში უნდა დარჩეს, და გადაწყვიტეთ, რა მოხდება, როცა ძებნა არჩეულ ცხრილში ვერაფერს იპოვის. ცხადი სარეზერვო მარშრუტი უფრო ადვილი დასაფიქრებელია, ვიდრე ცარიელი ცხრილი, რომელიც მიუწვდომელ შედეგს აბრუნებს და აპლიკაციას გატეხილად აჩვენებს და არა არასწორად მიმართულად.

ჰკითხეთ ძიებას ის კითხვა, რომელსაც თქვენი აპლიკაცია სვამს

ip route get ხსნის გზას; ip route show ჩამოთვლის შენახულ ჩანაწერებს და ორივე შეიძლება არ დაეთანხმოს ერთმანეთს, თუმცა არც ერთი არ არის მცდარი. ჩართეთ წყაროს კონტექსტი, რადგან წყაროზე დაფუძნებული წესები ემთხვევა მხოლოდ მაშინ, როცა ძიება წყაროს ატარებს.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

პირველი ბრძანება კითხვას ჰოსტის მხრიდან სვამს. მეორე ამატებს შემავალ ინტერფეისს, რაც უფრო ახლოსაა იმასთან, რასაც გადაგზავნილი ტრაფიკი განიცდის, და პასუხი ხშირად სხვა ცხრილზე მიუთითებს. არც ერთი დანიშნულება არ არის ცოცხალი სატესტო სერვისი; 198.51.100.23 დოკუმენტაციის მისამართია, ამიტომ ჩაანაცვლეთ ის ჰოსტით, რომლის გამოკვლევაც დაშვებული გაქვთ.

სწორი ძებნაც კი მხოლოდ იმას ამტკიცებს, რომ გზა აირჩიეს. ის არაფერს ამბობს იმაზე, მიიღებს თუ არა მოპირდაპირე მხარე ტრაფიკს ან შეიძლება თუ არა პასუხი დაბრუნდეს იმავე მსჯელობით.

სად ტრიალდება შედარება

ჰოსტის ტრაფიკი და გადაგზავნილი ტრაფიკი არა მხოლოდ სხვადასხვა ძიებას აკეთებს; დაბრუნების გზაზე ისინი სხვადასხვა ფილტრს ხვდებიან. Linux საპირისპირო გზის ვალიდაციას იყენებს ყველა ინტერფეისის და მიმღები ინტერფეისის პარამეტრებიდან უფრო მკაცრით, ამიტომ ერთი ინტერფეისის მნიშვნელობის შეცვლას შეიძლება არ ჰქონდეს ხილული ეფექტი. ნიშანზე დაფუძნებული მარშრუტიზაცია ამატებს src_valid_mark დამოკიდებულებას, სადაც ნიშანი უნდა დაემთხვეს, რომ წყარო ვალიდურად ჩაითვალოს.

თუ პასუხები ქრება, სანამ გამავალი მარშრუტიზაცია სწორად გამოიყურება, წაიკითხეთ მოქმედი მნიშვნელობები მათზე შეხებამდე, და შეცვალეთ ისინი მხოლოდ გამოცხადებული პოლიტიკის მიზეზით.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

ორ დიზაინს შორის აირჩიეთ მტკიცებულებების საფუძველზე: თუ აპლიკაცია PPP მისამართზე იკავშირებს თავს, საკმარისია წყაროს წესი და ცხრილი peer-ის მარშრუტით. თუ ყუთი გადასცემს მის უკან მდგარ LAN-ს, საჭიროა აგრეთვე, რომ შემავალი კონტექსტი და დაბრუნების გზა დაემთხვეს. როცა ისინი არ ემთხვევა, შეასწორეთ მარშრუტის კუთვნილება მთელი მანქანის ვალიდაციის შესუსტების ნაცვლად.