OpenVPN-ის მარშრუტის მეტრიკა: რატომ მაინც აგებს არჩეული მარშრუტი
თითო მარშრუტის მეტრიკა და route-metric სხვადასხვა რამეს აყენებს. გაიარეთ პროფილის ხაზი, შეამოწმეთ რა დააყენა კლიენტმა და ნახეთ, რატომ მაინც აგებს უფრო მცირე რიცხვი.
პროფილში მარშრუტს მეტრიკა დაამატეთ, ხელახლა დაუკავშირდით და ტრაფიკი მაინც არასწორი ინტერფეისიდან გადის. რიცხვი იშვიათად არის პრობლემა. მეტრიკა მხოლოდ იმ კანდიდატებს ალაგებს, რომლებსაც ოპერაციული სისტემა უკვე ადარებს, ხოლო უფრო კონკრეტული პრეფიქსი ან უფრო ადრეული პოლიტიკის ცხრილი წყვეტს ნებისმიერი მეტრიკის წაკითხვამდე.
ჯერ პროფილი გაიარეთ, შემდეგ დაყენებული ცხრილი, შემდეგ შერჩევის წესები. ეს თანმიმდევრობა ემთხვევა იმას, თუ როგორ აშენებს კლიენტი მარშრუტს და გიშლით ხელს დაარეგულიროთ მნიშვნელობა, რომელიც შედარებაში არასდროს შედის.
წაიკითხეთ მარშრუტის ხაზი ველების რიგით
OpenVPN 2.6-ის საზოგადო კლიენტი IPv4 route ხაზზე ოთხ ველს იღებს: ქსელი, ქსელის ნიღაბი, კარიბჭე და არასავალდებულო მეტრიკა. კარიბჭის პოზიცია ის ადგილია, სადაც სპეციალური საკვანძო სიტყვა vpn_gateway მიდის. ეს ნიშნავს ამ კავშირისთვის VPN მხარის შემდეგ ნახტომს, არა მარშრუტიზაციის ცხრილის ნომერს და არა თქვენს ფიზიკურ როუტერს. თუ ეს გამოგრჩათ, ხაზის დარჩენილი ნაწილი იკითხება არასწორი წარმოდგენით, თუ რას აკეთებს ის. ქსელის პარამეტრების ცნობარი ოთხივე ველს აღწერს.
კერძო დანიშნულებისთვის ხაზი ასე შეიძლება იკითხოს:
route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30
გამოკვეთილი 30 ეხება ამ მარშრუტს, ხოლო 50 რჩება ნაგულისხმევად პროფილის ყველა სხვა მარშრუტისთვის, რომელიც რიცხვს გამოტოვებს. ხაზის მარცხნიდან მარჯვნივ წაკითხვა საკმარისია იმის გასაგებად, რომელი მნიშვნელობა სად მოქმედებს.
route-metric ნაგულისხმევია და არა რანგი
route-metric ადგენს სარეზერვო მნიშვნელობას იმ მარშრუტებისთვის, რომლებსაც საკუთარი რიცხვი არ აქვთ. ის არც ერთ მარშრუტს არ აწევს სხვა რამეზე მაღლა და არ ალაგებს ხელახლა გამოკვეთილი მეტრიკებით დაყენებულ მარშრუტებს.
ეს განსხვავება მნიშვნელოვანია, როცა პროფილი ორივე ფორმას ურევს. ზემოთ ახლოს მდებარე ერთი route-metric ხაზი ავტორიტეტულად გამოიყურება და ადვილი დასაბრალებელია, მაშინ როცა მარშრუტი, რომელიც ტრაფიკს რეალურად ატარებს, შეიძლება საკუთარი მეტრიკა სამი ხაზით ქვემოთ ატარებდეს.
თუ გსურთ, ერთმა მარშრუტმა უპირატესობა მისცეს გზას, ჩასვით რიცხვი სწორედ იმ მარშრუტში. თუ გსურთ თანმიმდევრული ნაგულისხმევი მნიშვნელობა გენერირებულ პროფილში, გამოიყენეთ route-metric და ცალკეული ხაზები ისე დატოვეთ. ორივეს მიზეზის გარეშე შერევა ის გზაა, რომლითაც პროფილი მთავრდება მარშრუტით, რომელსაც ვერავინ ხსნის.
შეამოწმეთ, რა დააყენა კლიენტმა
გადაკავშირების დასრულების შემდეგ ჰკითხეთ ბირთვს და არა პროფილს.
ip route show ჩამოთვლის კლიენტის მიერ დამატებულ მარშრუტებს, ხოლო ip route get 172.20.5.10 პასუხობს უფრო სასარგებლო კითხვას: რომელ მარშრუტს გამოიყენებდა ეს დანიშნულება რეალურად და რომელი წყაროს მისამართით. თუ დანიშნულება ცხრილში არ არის, კლიენტმა ის არ დააყენა.
ლოკალური დირექტივა, სერვერის ბიძგი ან სხვა ქსელის მენეჯერი შეიძლება დაამატოს ან წაშალოს იგივე პრეფიქსი და იმარჯვებს ის, ვინც ბოლოს წერს. მუშაობისას თვალწინ გქონდეთ საბოლოო წერტილის მარშრუტი, რადგან კავშირს სჭირდება გზა დისტანციურ სერვერამდე, რომელიც არ გადის იმ გვირაბში, რომელსაც ის აშენებს.
რატომ აგებს უფრო მცირე მეტრიკა მაინც
მეტრიკები ადარებენ მარშრუტებს იმავე დანიშნულებამდე. ისინი ფართო პრეფიქსს უფრო კონკრეტულს არ ხდიან. როცა redirect-gateway def1 მოქმედებს, კლიენტი აყენებს 0.0.0.0/1-ს და 128.0.0.0/1-ს, და ეს ორი პრეფიქსი მთელ IPv4 სივრცეს ფარავს უფრო კონკრეტულად, ვიდრე 0.0.0.0/0. ნაგულისხმევ მარშრუტზე 1 მეტრიკა მათ არ აღემატება.
იგივე ლოგიკა ეხება ნებისმიერ გადამფარავ წყვილს. /24 იმარჯვებს /16-ზე მის შიგნით მდებარე მისამართისთვის, მიმაგრებული რიცხვების მიუხედავად, რადგან ძებნა ჯერ ყველაზე კონკრეტულ დამთხვევას ირჩევს და მხოლოდ შემდეგ ადარებს მეტრიკებს თანაბრებს შორის.
ეს ის ნაწილია, რომელიც მეტრიკის შეცდომას ჰგავს და არ არის. ნებისმიერი რიცხვის შეცვლამდე შეამოწმეთ პრეფიქსის სიგრძე ორივე კანდიდატზე.
პოლიტიკის წესები ცხრილამდე მუშაობს
Linux-ზე ip rule განსაზღვრავს, რომელ მარშრუტიზაციის ცხრილს მიმართავენ. წესები შეფასდება პრიორიტეტის რიგით, ამიტომ ადრეულ ცხრილს შეუძლია მარშრუტი დააბრუნოს მანამ, სანამ ძირითად ცხრილს საერთოდ წაიკითხავენ. main-ის შიგნით მყოფი მეტრიკა ვერ აღემატება იმ ცხრილის დამთხვევას, რომელსაც პირველად მიმართეს.
გამოიყენეთ ip rule show და შემდეგ ჰკითხეთ კონკრეტულ ცხრილს, მაგალითად ip route show table 100-ს, რომ ნახოთ, რას დააბრუნებდა ეს წესი. თუ VPN კლიენტმა ან კონტეინერის გაშვების გარემომ წესი დაამატა, პასუხი შეიძლება იქ იყოს და არა იმ ცხრილში, რომელსაც კითხულობდით. წყაროს მისამართიც მნიშვნელოვანია, რადგან წესი შეიძლება წყაროს დაემთხვეს და იგივე დანიშნულება სხვაგვარად გადაჭრას გვირაბის ტრაფიკისა და LAN ტრაფიკისთვის.
შეამოწმეთ დანიშნულება და არა რანჟირება
კამათის დამამთავრებელი ტესტი არის ერთი მოთხოვნა განკუთვნილი ქვექსელის შიგნით მყოფ ჰოსტთან, პლუს ბირთვის მიერ არჩეული წყაროს მისამართის შემოწმება. თუ ეს წყვილი ემთხვევა დიზაინს, მეტრიკა თავის საქმეს აკეთებს მაშინაც, როცა სია სუფთა რანჟირებას არ ჰგავს.
დატოვეთ IPv6 და DNS ამ შემოწმების გარეთ. ისინი სხვა დირექტივებით კონფიგურდება და სხვა მექანიზმებით წყდება, ხოლო მომუშავე IPv4 მარშრუტი არც ერთ მათგანზე არაფერს ამბობს. ერთდროულად ერთი შრე შეცვალეთ და მოთხოვნა ხელახლა გაუშვით.