მარშრუტიზაციის ცხრილი და რეალური ძიება: სად მიდის VPN ტრაფიკი

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

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

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

ძიება გადის ჯერ წესებს, შემდეგ ცხრილებს

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6-ს აქვს საკუთარი წესები და ცხრილები. ორივე ოჯახზე მომუშავე დიზაინს ორივე ძიება სჭირდება, და მომუშავე IPv4 პასუხი არაფერს ამბობს v6 გზაზე, რომელსაც ორსტეკიანი კლიენტი შეიძლება ამჯობინებდეს.

რას აყენებს VPN კლიენტი

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

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

გარე მარშრუტმაც უნდა გადარჩეს

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

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

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

რა ვერ გეტყვით მარშრუტიზაციის გამომავალმა

სწორი ძიება ნიშნავს, რომ ბირთვი პაკეტს გონივრულ ადგილას გაგზავნიდა. ეს არ ნიშნავს, რომ firewall უშვებს, IPsec პოლიტიკა ფარავს, NAT წესი თარგმნის ან შორეულ მხარეს დაბრუნების მარშრუტი აქვს. თითოეული მათგანი შემდგომი ეტაპია, და strongSwan-ის გადაცემის შენიშვნები აღწერენ ჯაჭვს, რომელიც პაკეტმა ორივე ბოლოში უნდა გაიაროს.

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

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