MULTI: არასწორი წყაროს მისამართი კლიენტისგან: ეს ვისი მისამართი იყო?
შიდა წყარო არ ემთხვევა იმ კლიენტს, რომელმაც ის მოიტანა. შეუსაბამეთ ის გვირაბის მინიჭებას, კლიენტის უკან არსებულ LAN-ს ან დუბლირებულ იდენტობას.
სერვერის ჟურნალი ბეჭდავს MULTI: bad source address from client-ს, აგდებს პაკეტს და სესია დაკავშირებული რჩება. ეს კომბინაცია აბნევს მათ, ვინც შეტყობინებას ავთენტიფიკაციის წარუმატებლობად კითხულობს. ასე არ არის: კლიენტმა ავთენტიფიკაცია გაიარა და მოსული პაკეტი ატარებდა შიდა წყაროს მისამართს, რომლის დაკავშირებაც სერვერმა ამ კლიენტის ინსტანციასთან ვერ შეძლო. შემოწმება მიწოდებამდე ხდება, ამიტომ გვირაბი ჯანმრთელად გამოიყურება, თუმცა მისგან არაფერი სასარგებლო არ გადის.
რას ადარებს სერვერი მიწოდებამდე
კლიენტისგან მომავალი ყოველი პაკეტისთვის მომხმარებლის სივრცის სერვერი უყურებს გვირაბის შიგნით არსებულ წყაროს მისამართს და ეკითხება საკუთარ შიდა მარშრუტიზაციის მდგომარეობას, რომელ კლიენტს ეკუთვნის ეს მისამართი. თუ მფლობელი სხვა ინსტანციაა, ან საერთოდ არ არის მფლობელი, პაკეტი უქმდება და გაფრთხილება გაიცემა.
გვირაბის ინტერფეისით ჩვეულებრივი მიწოდება არასდროს ხდება.
ეს თანმიმდევრობა ხსნის დეტალს, რომელიც ადამიანებს აკვირვებს: მასპინძლის ქსელური დამცავი კედლის მრიცხველები არ იძვრება, რადგან პაკეტი დამცავ კედელს არასდროს მიუღწევია. მასპინძელზე საპირისპირო გზის ფილტრაციის რეგულირება აქ არაფერს ცვლის, ვინაიდან უარი დემონის საკუთარი კავშირის შემოწმებაში მოხდა. წაიკითხეთ შეტყობინება როგორც განაცხადი საკუთრებაზე, შემდეგ კი გაარკვიეთ, სამი სიტუაციიდან რომელმა შექმნა ის.
შეუსაბამო შიდა მისამართის სამი წყარო
კლიენტმა შეიძლება გააგზავნოს ისეთი მისამართიდან, რომელიც მას არ მიენიჭა, ისეთი ქსელიდან, რომელიც არავინ არ გამოაცხადა მისად, ან ისეთი იდენტობის ასლიდან, რომელსაც უკვე ჰყავს მფლობელი. სამივე ერთსა და იმავე ჟურნალის ხაზს ქმნის. ისინი იმით განსხვავდებიან, რისი შეცვლაც გმართებთ. დაიწყეთ მისამართითა და მიმდინარე მინიჭებების სიით და მიეცით ამ ორ ფაქტს შემთხვევის არჩევის საშუალება.
მათი გარჩევა ორ ფაქტს მოითხოვს: ჟურნალში უარყოფილ მისამართს და იმ მინიჭებებს, რომლებსაც სერვერი მიმდინარედ თვლის. მეორე ხელმისაწვდომია მოქმედი ინსტანციის სტატუსის ან მართვის ხედიდან და ეს არის ერთადერთი ხელისუფლება, რომელსაც ღირს მიმართოთ, რადგან კონფიგურაციის ფაილი განზრახვებს აფიქსირებს და არა ახლანდელ მდგომარეობას.
ჩაწერეთ ორივე, სანამ რამეს შეცვლით, შემდეგ კი დაალაგეთ. მოგვიანებით გადაღებული ეკრანის სურათი არ არის იმ მდგომარეობის ჩანაწერი, რომელმაც გაფრთხილება წარმოშვა. შეინახეთ დროის ნიშნულიც, რადგან მინიჭებები სესიებს შორის ინაცვლებს.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
კლიენტის უკან არსებული LAN და iroute
როცა საიტის კლიენტი თავისივე კერძო ქსელს მარშრუტიზაციას უკეთებს, ეს ქსელი კლიენტის კუთვნილად უნდა გამოცხადდეს. iroute ჩანაწერის მქონე კლიენტისთვის სპეციფიკური ფაილი ამას აკეთებს და ჩანაწერი ასახელებს იმ პრეფიქსს, რომლის ტარების უფლებაც კლიენტს აქვს.
ბირთვის მარშრუტი, რომელიც იმავე პრეფიქსს გვირაბისკენ მიმართავს, ცალკე მოთხოვნაა და მისი დამატება დემონის შიდა საკუთრებაში არაფერს ცვლის.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0დაადასტურეთ, რომ ეფექტური იდენტობა ფაილის სახელს ემთხვევა, ვინაიდან შეუსაბამობა ნიშნავს, რომ ფაილი არასდროს იტვირთება და სიმპტომი იდენტურია დაკარგული ჩანაწერისა. ნუ დაამატებთ ფართო iroute-ს გაფრთხილების ჩასახშობად, ვინაიდან ეს გასაკვირ წყაროს ნებადართულად აქცევს და არ პასუხობს, რატომ გაგზავნა ის კლიენტმა. OpenVPN 2.6-ის სახელმძღვანელო iroute-ს, duplicate-cn-ს და იდენტობის ასახვას ცალკე კონტროლებად აღწერს.
ერთი და იგივე იდენტობა ორ მანქანაზე
მეორე ლეპტოპზე დაკოპირებული პროფილი ერთსა და იმავე სერტიფიკატს და ერთსა და იმავე საერთო სახელს ატარებს. სერვერის პარამეტრებიდან გამომდინარე, ახალმა კავშირმა შეიძლება ძველი ჩაანაცვლოს და კავშირის შემოწმებას ის ინსტანცია იგებს, რომელსაც საკუთრება აქვს.
ეს ხარვეზს წყვეტილად აჩენს და ის მხოლოდ მაშინ ვლინდება, როცა ორივე მოწყობილობა ფხიზლადაა.
დუბლირებული საერთო სახელების დაშვება ორივეს აკავშირებს, მაგრამ არ აძლევს მათ დამოუკიდებელ სტატიკურ მისამართებს ან დამოუკიდებელ საკუთრებას. თუ ორი მოწყობილობა ერთად უნდა არსებობდეს, დაარეგისტრირეთ ისინი ცალ-ცალკე, რათა თითოეულს თავისი იდენტობა და თავისი მინიჭება ჰქონდეს. დუბლირების პარამეტრის ამ გაფრთხილების შეკეთებად მიჩნევა გამოცანას ადგილზე ტოვებს და მეორეს ამატებს.
დაამტკიცეთ, რომ კავშირი შეიცვალა
გამოიყენეთ შესწორება კონფიგურაციის მფლობელის მეშვეობით, შემდეგ კი ხელახლა შეაერთეთ დაზარალებული კლიენტი, რათა ახალი პოლიტიკა ჩაიტვირთოს.
გაიმეორეთ იგივე ნაკადი და დაადასტურეთ სამი რამ: პაკეტის შიდა წყარო, კლიენტის ის ინსტანცია, რომელთანაც სერვერი მას აკავშირებს და დანიშნულების ქცევა ამის შემდეგ.
თუ გაფრთხილება წყდება, მაგრამ აპლიკაცია კვლავ ვარდება, პრობლემა გადაადგილდა და არ გაქრა. გადაგზავნა, დამცავი კედლის წესები და დაბრუნების გზა ცალკე ეტაპებია და კავშირის შემოწმების გავლა მხოლოდ იმას ნიშნავს, რომ პაკეტს გვირაბის დატოვების ნება მიეცა.