რატომ არ აჩვენებს VPN მარშრუტი კარიბჭეს ip route-ის გამოსავალში
ხაზი მოწყობილობით და კარიბჭის გარეშე პირდაპირი მარშრუტია და არა გატეხილი. წაიკითხეთ დანიშნულება, dev და scope, შემდეგ დაადასტურეთ ip route get-ით.
მარშრუტიზაციის ცხრილებს ხშირად გატეხილად კითხულობენ, როცა კარიბჭის სვეტი ცარიელი რჩება, თუმცა ხაზი, როგორც წესი, თავისთავად სრულია. ველი via მხოლოდ მაშინ ჩნდება, როცა ბირთვი პაკეტს შემდეგი ნახტომის მისამართს გადასცემს; ინტერფეისზე მიმაგრებული მარშრუტი თავის დანიშნულებებს სამაგიეროდ კავშირის დონის გადაწყვეტით ან წერტილ-წერტილ წყვილთან კავშირით აღწევს. სვეტების მარცხნიდან მარჯვნივ კითხვა გეუბნებათ, რომელ შემთხვევაში ხართ, და ეს კითხვა უნდა მოხდეს მანამ, სანამ ვინმე ნაგულისხმევ მარშრუტს შეცვლის. დაკარგული კარიბჭის შესახებ ბილეთების უმეტესობა სწორედ ამ განსხვავებაზე მთავრდება.
წაიკითხეთ მარშრუტის ხაზი სვეტობრივად
თითოეული ჩანაწერი იწყება დანიშნულებით და მისი პრეფიქსის სიგრძით, შემდეგ კი ფიქსირებულ ლექსიკონში მოდიფიკატორებს ამატებს: via, dev, proto, scope, src და metric. 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2-ის მსგავსი ხაზი მკვრივია, მაგრამ სრულად განსაზღვრული. მასში არაფერი აკლია და არავითარი მარშრუტიზატორის მისამართი არ იგულისხმება.
საინტერესო ნაწილი via-ის არარსებობაა. შემდეგი ნახტომის გარეშე ბირთვი დანიშნულებას უშუალოდ მითითებულ ინტერფეისზე წყვეტს, რაც გვირაბისთვის ნიშნავს ჩარჩოს გვირაბის მოწყობილობისთვის გადაცემას და ინკაფსულაციისთვის იქიდან გადაბარებას. proto kernel აღნიშნავს, რომ ჩანაწერი ავტომატურად დაყენდა მისამართის მინიჭებისას და არა ადმინისტრატორის მიერ აკრეფილი. scope link ამბობს, რომ დანიშნულება ამ კავშირზე მარშრუტიზატორის გავლის გარეშე მისაწვდომია, ხოლო src ასახელებს მისამართს, რომელსაც ბირთვი შესაბამისი ტრაფიკის წყაროდ ამჯობინებს.
ახლა ნაგულისხმევი მარშრუტი იმავე გზით წაიკითხეთ: default via 192.0.2.254 dev eth0 proto static metric 100. აქ via იმიტომ არის, რომ პაკეტს ნამდვილად სჭირდება შემდეგი ნახტომი, და ეს ნახტომი თავად უნდა იყოს მისაწვდომი eth0-ზე. ეს ორი ხაზი ერთმანეთის ვარიანტები არ არის; ისინი განსხვავებულ კითხვებს პასუხობენ იმაზე, თუ სად მიდის ტრაფიკი.
ორი მარშრუტის ფორმა, რომლებიც ერთმანეთში ირევა
გვირაბის ქვექსელის მარშრუტი და ნაგულისხმევი მარშრუტი ეკრანის სურათზე მსგავსად გამოიყურება და სრულიად განსხვავებულად იქცევა. გამოიყენეთ ქვემოთ მოცემული ცხრილი ველების კითხვის დასახმარებლად, შემდეგ კი დაადასტურეთ რეალური რიცხვები იმ მანქანაზე, რომელსაც ამოწმებთ, ნაცვლად იმისა, რომ სახელმძღვანელოს ნიმუშს დაეყრდნოთ.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
რასაც ცხრილი ვერ გეტყვით, განზრახვაა. გვირაბის გავლით კერძო დიაპაზონისკენ პირდაპირი მარშრუტი განზრახ დაყოფილი გვირაბის დიზაინია; იგივე ფორმა ჰოსტზე, რომელმაც ყველაფერი VPN-ით უნდა გაგზავნოს, სიმპტომია. განზრახვა ცხოვრობს იმ კონფიგურაციაში, რომელმაც ჩანაწერი შექმნა, ამიტომ შეხედეთ იმ ხელსაწყოს, რომელმაც ის დააყენა, სანამ დაასკვნით, რომ ბირთვმა რაღაც არასწორად გააკეთა.
ანალოგიურად, დაკარგული კარიბჭე არ არის მისი გამოგონების ნებართვა. თუ მარშრუტს ნამდვილად სჭირდება შემდეგი ნახტომი, ეს ნახტომი უნდა იყოს მისაწვდომი იმ ინტერფეისზე, რომელიც მას ატარებს, და წერტილ-წერტილ გვირაბისთვის წყვილის მისამართი იგივე ობიექტი არ არის, რაც ლოკალური მისამართი. ლოკალური გვირაბის მისამართის Ethernet მარშრუტიზატორად განხილვა გავრცელებული გზაა იმისთვის, რომ შეიქმნას მარშრუტი, რომელიც სწორად გამოიყურება და არაფერს გადასცემს.
ჰკითხეთ ბირთვს, რომელ ხაზს გამოიყენებს ის რეალურად
ცხრილის კითხვა იგივე არ არის, რაც ძიების შესრულება, რადგან ბირთვი პასუხამდე კონსულტაციას უწევს პოლიტიკის წესებს, რამდენიმე ცხრილს და ქეშირებულ ჩანაწერებს. ზმნა, რომელიც რეალურ ძიებას ასრულებს, არის ip route get, და ის ბეჭდავს იმ მარშრუტს, რომელსაც ამ თვისებების მქონე პაკეტი აირჩევდა.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0ჩაანაცვლეთ იმ დანიშნულებით, რომელიც ნამდვილად გაღელვებთ, შემდეგ კი დაამატეთ from ან iif, როცა ტრაფიკი წყაროს მიხედვით არჩეულია ან გადაეცემა, რადგან ჩვეულებრივმა ლოკალურმა ძიებამ შეიძლება სხვა გზა აირჩიოს, ვიდრე გადაცემულმა კლიენტმა. პასუხი ასახელებს ინტერფეისს, არჩეულ წყაროს მისამართს და ნებისმიერ შემდეგ ნახტომს, რაც იგივე ინფორმაციაა, რომლითაც პაკეტი იმ მომენტში მარშრუტიზდებოდა.
თუ პასუხი გაგაოცათ, დაბეჭდეთ წესები სანამ რამეს შეცვლით: ip -4 rule show ჩამოთვლის მათ პრიორიტეტის მიხედვით, და VPN კლიენტი, რომელიც საკუთარ ცხრილს ან მონიშნული პაკეტებისთვის წესს აყენებს, მთავარ ცხრილში საერთოდ არ გამოჩნდება. ყველა ცხრილის ჩამოთვლა ამ ხარვეზს ხურავს.
ip -4 route show table all | grep -E 'tun|default'შეამოწმეთ ქვედა შრე, სანამ ნაგულისხმევს შეცვლით
გვირაბის საკუთარი პაკეტები უნდა მიაღწიონ შორეულ ბოლო წერტილს, და ამას აკეთებენ ფიზიკური ინტერფეისის გავლით იმ მარშრუტის გამოყენებით, რომელიც არსებობდა VPN-ის ამოქმედებამდე. მთელი ნაგულისხმევი მარშრუტის შეცვლა ამ ბოლო წერტილის დამაგრების გარეშე ინკაპსულირებულ პაკეტებს იმ გვირაბში აგზავნის, რომელიც მათ უნდა აეგოთ, და კავშირი ინგრევა. ჯერ დაადასტურეთ ბოლო წერტილის გზა მხოლოდ მისი მისამართის ძიებით.
ცვლილების გაკეთებისას სამი რამ ცალ-ცალკე შეინახეთ: ბოლო წერტილის მარშრუტი, რომელიც ფიზიკურ ინტერფეისზე უნდა დარჩეს, კერძო დიაპაზონები, რომლებიც გვირაბში უნდა შევიდეს, და ნაგულისხმევი, რომელიც დანარჩენ ყველაფერს წყვეტს. დაყავით ისინი ამ თანმიმდევრობით, გამოიყენეთ თითო ერთდროულად და ყოველი ნაბიჯის შემდეგ ხელახლა გაუშვით ძიება. მოგვიანებით წარუმატებელი ping თავისთავად ძალიან ცოტას ამტკიცებს, რადგან ნებართვები, პასუხების მარშრუტიზაცია, DNS და თავად სერვისი ყველა სწორი მარშრუტის ქვემოთ ზის.
ჩამოწერეთ ოთხი მნიშვნელობა, რომლებიც ხაზმა მოგცათ რედაქტირებამდე: დანიშნულება, შემდეგი ნახტომი ან მისი არარსებობა, მოწყობილობა და არჩეული წყარო. თუ მოგვიანებით ცვლილება რომელიმეს გადააადგილებს, თქვენ იცით, რომელი გადაწყვეტილება შეიცვალა სინამდვილეში, და შეგიძლიათ აღადგინოთ ერთი ჩანაწერი, ნაცვლად იმისა, რომ მთელ ცხრილზე გამოიცნოთ.