ორი მფლობელი, ერთი მისამართი: დუბლირებული IP TAP ხიდზე

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

წაიკითხეთ კონფლიქტის მტკიცებულებები, სანამ ხიდს შეეხებით

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

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

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

აღწერეთ სეგმენტის ყველა მოთხოვნა

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

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

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

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

დანომრეთ ხიდები მხოლოდ იქ, სადაც იდენტობა სჭირდებათ

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

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

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

გახადეთ შესწორება გადატვირთვისადმი მედეგი

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

იპოვეთ ამ კონფიგურაციის მფლობელი: ქსელის მმართველის პროფილი, ინტერფეისის ფაილი, კონტეინერის ან VM-ის განსაზღვრება, ან cloud-init ფრაგმენტი. შეცვალეთ ის იქ, შემდეგ განზრახ გადატვირთეთ ერთი დაზარალებული ჰოსტი, რათა დაადასტუროთ, რომ ახალი მნიშვნელობა ბრუნდება. გადატვირთვა ერთადერთი გამოცდაა, რომელიც მუდმივობას ამტკიცებს.

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

დაამტკიცეთ ეს ყველა კლიენტის ონლაინ ყოფნისას

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

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

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

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