IPv6 პოლიტიკის მარშრუტიზაცია, როცა ორი აპლინკი fe80::1-ს იზიარებს

ორი აპლინკი გაქვს და ip -6 route show ორივეზე ერთსა და იმავე შემდეგ ნახტომს ბეჭდავს: default via fe80::1 dev uplink0 და default via fe80::1 dev uplink1. ეს არ არის დუბლირებული მისამართის კონფლიქტი და შიშველი შემდეგი ნახტომის fe80::1 პოლიტიკის ცხრილში კოპირება კერნელს არ ეუბნება, რომელი ბმული გქონდა მხედველობაში. ნამდვილი კითხვა სიმპტომზე ვიწროა: მეორე ცხრილს ერთი ბმული სჭირდება თუ ორივე, და რა ინარჩუნებს ამ მარშრუტებს ცოცხლად გადატვირთვის შემდეგ. სამი პირობა, რიგრიგობით შემოწმებული, უმეტესობას წყვეტს.

იგივე fe80::1 ორი სხვადასხვა მეზობელია

ბმულ-ლოკალური მისამართები ერთ ბმულზეა შემოსაზღვრული, ამიტომ fe80::1 ორჯერ დაბეჭდილი ერთი მისამართი არ არის; ეს ორი მეზობელია, რომლებიც შემთხვევით ერთსა და იმავე სუფიქსს იზიარებენ. ზონის ინდექსია ის გზა, რომლითაც ჰოსტი ამბობს, რომელი იგულისხმება, ამიტომ fe80::1%uplink0 და fe80::1%uplink1 კერნელისთვის სხვადასხვა დანიშნულებაა, და ეს სუფიქსი არასოდეს მიდის დისტანციურ როუტერთან. RFC 4007 აღწერს ამის უკან მდგარ ზონის მოდელს და სწორედ ამიტომ პოლიტიკის ცხრილს ყოველ ბმულ-ლოკალურ შემდეგ ნახტომთან ერთად მოწყობილობა უნდა ჰქონდეს.

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

მოწყობილობას მოაშორე და მარშრუტი დაუწერელი ხდება. ip -6 route add default via fe80::1 table 200 ვერ ხსნის კარიბჭეს და iproute2 მას Error: Nexthop has invalid gateway.-ით უარყოფს; დაამატე dev uplink0 და ბრძანება წარმატდება, რადგან მოწყობილობაა ის, რაც შემდეგ ნახტომს ამ ორი მეზობლიდან ერთზე ამაგრებს. რასაც მოწყობილობა ვერ გეტყვის, არის ის, თუ uplink0 სწორი ბმულია ამ ცხრილისთვის და სხვა ჰოსტიდან დაკოპირებული მარშრუტი თან მოაქვს იმ ჰოსტის ინტერფეისების სახელებს, საიდანაც ნამდვილი შეცდომები მოდის.

პირობა ერთი: ერთი ბმული თუ ორი ცხრილში

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

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

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

არც ერთი ობიექტი არ ცვლის მეორეს და მხოლოდ ნაგულისხმევის შემცველი ცხრილიც შეიძლება ჩავარდეს კარიბჭის ამოხსნაში. თუ დამატება უარყოფილია, ან მარშრუტი არსებობს, მაგრამ გამოუსადეგარია, ჩასვი ამ ინტერფეისის მიერთებული პრეფიქსი იმავე ცხრილში, ან მონიშნე ნახტომი როგორც onlink, როცა ეს პრეფიქსი სხვაგან მარშრუტიზდება. ზემოთ ბლოკში 2001:db8:100::/48 წარმოადგენს სწორედ ამ მიერთებულ პრეფიქსს uplink1-ზე და არა თვითნებურ დანიშნულებას. fwmark წესი მხოლოდ იმ ნიშანს მოიხმარს, რომელიც სხვამ უნდა დასვას, გადაცემის გზაზე nftables ან iptables წესიდან ან სოკეტზე SO_MARK-იდან, ამიტომ ნიშნის წყაროს გარეშე დაკოპირებული ბლოკი არაფერს ემთხვევა.

პირობა ორი: მეტრიკები მკვდარ პროვაიდერს არ ავლენენ

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

ცხრილის აწყობის შემდეგ გადაამოწმე არჩევანი და გადაამოწმე ისე, როგორც კერნელი დაინახავს. ip -6 route get 2001:db8:100::1 ბეჭდავს მარშრუტს, რომელიც გამოიყენება, მოწყობილობისა და არჩეული წყაროს მისამართის ჩათვლით, და ის პატივს სცემს პოლიტიკის წესებს. არასწორი აპლინკის წყაროს მისამართი ჩვეულებრივი ნიშანია იმისა, რომ წესი უფრო ადრე დაემთხვა, ვიდრე ელოდი.

პირობა სამი: გადაწყვიტე, ვინ ფლობს მდგრადობას

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

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

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

როუტერზე, რომელიც სხვა ჰოსტებისთვის გადასცემს, სანამ ცხრილს დაადანაშაულებ, შეამოწმე net.ipv6.conf.all.forwarding. გადაცემის გამორთვისას სხვა ქსელში მიმართული პაკეტები ყრიალდება, რამდენად სწორიც არ უნდა იყოს ცხრილი 201.

ჩაწერე დიზაინი, რომ შემდეგმა ადამიანმა შეძლოს მისი აუდიტი

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

სანამ ცხრილს დასრულებულად გამოაცხადებ, დაადასტურე მეზობელი ip -6 neigh show dev uplink0-ით, თავიდან წაიკითხე ip -6 rule show რიგის შემთხვევებისთვის და გამოსცადე წესს შესაბამისი ტრაფიკით და არა ping-ით, რომელიც ნაგულისხმევ მარშრუტს იღებს. შემდეგ განზრახ ჩამოწიე ერთი აპლინკი და დააკვირდი, რომელ მარშრუტზე ბრუნდება კერნელი; პასუხი უნდა დაემთხვეს იმას, რაც ჩაწერე.