VPN კლიენტი შენს დამატებულ მარშრუტს შლის? გამოიყენე პოლიტიკის ცხრილი

ერთი /24 ლაბორატორიული პრინტერისთვის ქრება ip route show-ის ორ გამოძახებას შორის, და კლიენტის ჟურნალი მხოლოდ ამბობს, რომ ქსელი შეიცვალა. არაფერი იყო არასწორი ბრძანებაში, პრეფიქსში ან შენს უფლებებში. კორპორატიული კლიენტი, რომელიც ფლობს ჰოსტის მარშრუტიზაციის მოდელს, ხელახლა ამტკიცებს ამ მოდელს, როცა სხვა ვინმე არედაქტირებს მას, ამიტომ შენ მიერ დამატებული ჩანაწერი ინტრუზორად იშლება. იმავე ცხრილში მასთან ბრძოლა წაგებული პოზიციაა. გამოსავალია სრულად შეწყვიტო ამ ცხრილისთვის შეჯიბრი და გამონაკლისი იმ ადგილას განათავსო, საითაც მონიტორი არასდროს იხედება.

მონიტორი ხსნის დაკარგულ მარშრუტს

აჩვენე ეს, სანამ რამეს გადააკეთებ: წაიკითხე ცხრილი, დაამატე პრეფიქსი, დაელოდე რამდენიმე წამს, ისევ წაიკითხე. თუ ჩანაწერი არ არის და მის წასაშლელად არაფერი აკრიფე, ვიღაც აგენტი აკვირდება. იპოვე პროცესი, რომელიც ფლობს ამ ქცევას, და წაიკითხე მისი ჟურნალი მარშრუტის გაქრობის მომენტის ირგვლივ, რადგან ჩვეულებრივ იგივე სერვისი ინარჩუნებს გვირაბს, პაკეტების ფილტრებსა და resolver-ის კონფიგურაციას. მისი მოკვლა იმისთვის, რომ შენი მარშრუტი დარჩეს, გარიგებაა, რასაც შემდეგ ხელახლა დაკავშირებისას ინანებ.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

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

მეორე ცხრილი მონიტორისთვის უხილავია

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

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

ააშენე გამონაკლისი და შემდეგ გააგებინე

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

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get წყვეტს მარშრუტს, რომელსაც ბირთვი გამოიყენებდა, მოწყობილობისა და წყაროს მისამართის ჩათვლით. ის არ ბეჭდავს ცხრილის იდენტიფიკატორს, ამიტომ შეუწყვილე ip rule show-ს, როცა გჭირდება დაადასტურო, რომელი ცხრილი იმარჯვა. ერთად ისინი პასუხობენ ერთადერთ მნიშვნელოვან კითხვას: გადის თუ არა ამ მისამართის ტრაფიკი იქიდან, სადაც გინდოდა?

იგივე იდეის სხვა ფორმები

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

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

ბოლო შემთხვევა ემთხვევა შემავალ ინტერფეისს და არა დესტინაციას, რაც სხვა ტიპის წესი და სხვა გონებრივი მოდელია. გადამისამართებულ ტრაფიკს ასევე სჭირდება ჩართული net.ipv4.ip_forward, და შორეულმა მხარემ უნდა დაამარშრუტოს წყაროს დიაპაზონი უკან ან თარგმნოს ის; ერთ მანქანაზე არსებული წესი არასდროს ქმნის გზის მეორე ნახევარს.

მოეპყარი წესს როგორც ერთჯერადს

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

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

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