OpenVPN-ის ადაპტერი Windows-ზე ციმციმებს? შეამოწმეთ დუბლირებული IP
Windows-ის ციმციმა ადაპტერი ხშირად მისამართების კონფლიქტია და არა დრაივერის შეცდომა. წაიკითხეთ მოვლენები 4198 და 4199, იპოვეთ მეორე მფლობელი და შემდეგ დაამაგრეთ უნიკალური მისამართები.
Windows-ზე OpenVPN-ის ადაპტერი, რომელიც იღებს მისამართს, აგდებს მას და იმეორებს ამას ყოველ რამდენიმე წამში, ჩვეულებრივ DHCP-ის შეცდომა არ არის. ადაპტერს ეუბნებიან, გამოიყენოს მისამართი, რომელზეც უკვე სხვა რაღაც პასუხობს, ამიტომ Windows არაგამოსაყენებლად ნიშნავს და კლიენტი თავიდან იწყებს. კლიენტის ჟურნალი მშვიდი რჩება, რადგან კონფლიქტი მის ქვემოთ წყდება, თავად ოპერაციული სისტემის ქსელურ სტეკში.
ეს განსხვავება მნიშვნელოვანია, რადგან გვირაბის კონფიგურაციაზე მიმართული ყოველი დიაგნოსტიკური ნაბიჯი სერვერის მხარეს დუბლირებულ მისამართს გამოტოვებს.
დაიწყეთ Windows-ის მოვლენების ჟურნალით და არა კლიენტის ჟურნალით
Windows მისამართების კონფლიქტებს სისტემურ ჟურნალში 4198 და 4199 მოვლენის ID-ებით აღრიცხავს. პირველი აცნობს მისამართისთვის აღმოჩენილ კონფლიქტს, მეორე აცნობს, რომ ინტერფეისმა ვერ გამოიყენა მისამართი, რომლითაც იყო კონფიგურირებული. არც ერთი OpenVPN-ს არ იხსენიებს, და სწორედ ამიტომ ადვილია მათი გამოტოვება.
ამოიღეთ ბოლო მოვლენები და შეადარეთ მათი დროის ნიშნები ადაპტერის განახლების ციკლს: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. კონფლიქტი ყოველ თხუთმეტ წამში ემთხვევა კლიენტს, რომელიც იმავე მისამართს ხელახლა ცდის მფლობელის წინააღმდეგ, რომელიც კვლავ პასუხობს მას. ერთჯერადი კონფლიქტი დაკავშირების დროს უფრო ერთჯერად შეჯახებაზე მიუთითებს. ნებისმიერ შემთხვევაში, შემდეგი კითხვაა, კიდევ ვის აქვს მისამართი.
სამი განლაგება ორ ჰოსტს ერთ მისამართზე აყენებს
ჰკითხეთ სერვერს, მისი აზრით ვის აქვს მისამართი, შემდეგ ჰკითხეთ ქსელს, ვინ პასუხობს მას. grep -H ifconfig-push /etc/openvpn/ccd/* ჩამოთვლის ყოველ დამაგრებულ გვირაბის მისამართს და სერთიფიკატს, რომელსაც ის ეკუთვნის. ip -4 neigh show dev tap0 აჩვენებს, რა ისწავლა ხიდმა მეორე დონეზე. ამ ორი სიის შედარება უმეტეს დუბლიკატს ერთ წუთზე ნაკლებ დროში პოულობს.
სამი განლაგება თითქმის ყველას ხსნის: client-config-dir-ის ჩანაწერი ერთ მისამართს ამაგრებს ორი სერთიფიკატისთვის, ხიდზე შეერთებული tap სეგმენტი მანქანას აძლევს მისამართს, რომელიც სხვა ჰოსტს უკვე სტატიკურად აქვს, ან მოძველებული იჯარის ფაილი აბრუნებს მისამართს, რომელიც ჯერ კიდევ დაკავშირებულ კლიენტს თავისად მიაჩნია. მესამე შემთხვევა ყველაზე მზაკვრულია, რადგან ifconfig-pool-persist განზრახ იმეორებს მისამართებს ცნობილი კლიენტებისთვის.
გახადეთ მისამართი უნიკალური, ნაცვლად იმისა რომ მისთვის იბრძოლოთ
ჩატვირთვის რიგი მხოლოდ იმას წყვეტს, დღეს ვინ მოიგებს, ამიტომ გადატვირთვის მიმდევრობაზე დაფუძნებული ნებისმიერი შესწორება დროებითად მიიჩნიეთ. მიეცით თითოეულ კლიენტს თავისი ifconfig-push ხაზი, ან გამოყავით სტატიკური მისამართები დიაპაზონიდან, რომელსაც არც ერთი ხიდის ან სერვერის ინტერფეისი არ ეხება. შეამოწმეთ კლიენტების სია დუბლირებული საერთო სახელებისთვისაც, რადგან duplicate-cn ორ სესიას ერთი იდენტობის და, შესაბამისად, ერთი დამაგრებული მისამართის გაზიარების უფლებას აძლევს. თუ ხიდზე შეერთებულ მოწყობილობას ნამდვილად სჭირდება ფიქსირებული მისამართი, გადაიტანეთ იგი საკუთარ ქვექსელში ან დაჯავშნეთ აუზიდან იმ ადგილას, რომელსაც სერვერი აღრიცხავს.
წაშალეთ persist ფაილი მხოლოდ მას შემდეგ, რაც იცით რა იჯარებს ინახავს, თორემ შემდეგი ხელახალი დაკავშირება იგივე მისამართებს კვლავ გასცემს.
გადატვირთეთ სწორი რიგით და დაადასტურეთ ერთი მფლობელი თითო მისამართზე
ცვლილება ჯერ სერვერზე გამოიყენეთ, შემდეგ კლიენტები ხელახლა დააკავშირეთ, რათა ყოველი მონაწილე შესწორებულ აუზზე დარეგისტრირდეს. კლიენტების პირველად გადატვირთვა მათ იმ მისამართებით ტოვებს, რომლებსაც სერვერი ჯერ კიდევ დაკავებულად მიიჩნევს. გადატვირთვის შემდეგ წაიკითხეთ სტატუსის ფაილი და დაადასტურეთ, რომ ყოველი საერთო სახელი ერთხელ, ერთი მისამართით ჩანს. ერთი სახელისთვის ორი ჩანაწერი ნიშნავს, რომ ძველი სესია არასდროს დაიხურა და არა ის, რომ აუზი გატეხილია.
თუ კლიენტი კვლავ ვერ ინარჩუნებს თავის მისამართს, შეამოწმეთ, ხომ არ ატარებს მას იმავე ჰოსტის ხიდის ინტერფეისი. ხიდი, რომელმაც მისამართი მომწოდებლის მოწყობილობისგან მემკვიდრეობით მიიღო, ARP-ით უპასუხებს მას მაშინაც კი, როცა VPN-ის სერვერმა ეს მისამართი უკვე კლიენტს გადასცა.
დააკვირდით სრულ განახლების ციკლს სანამ ბილეთს დახურავთ
ერთი სუფთა წაკითხვა არაფერს ამტკიცებს. დააკვირდით ადაპტერს სულ მცირე ათი წუთი და შუაში აიძულეთ ხელახალი დაკავშირება: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. მისამართმა უნდა გადაიტანოს ხელახალი დაკავშირება და დარჩეს სასურველ მდგომარეობაში.
შემდეგ კვლავ გაუშვით პირველი ნაბიჯის მოვლენების მოთხოვნა და დაადასტურეთ, რომ ახალს არაფერს აბრუნებს. ხელახალი დაკავშირების განმავლობაში მშვიდი ჟურნალი იმის მტკიცებულებაა, რომ კონფლიქტი გაქრა, ხოლო ერთი დაკავშირების შემდეგ მშვიდი ჟურნალი მხოლოდ იმას ნიშნავს, რომ რბოლა ჯერ არ მომხდარა. დაბოლოს, შეამოწმეთ ის რესურსი, რომლისთვისაც გვირაბი არსებობს, რადგან მისამართის დაკარგულ ხიდს შეუძლია მომწოდებლის გზა გატეხოს, მაშინ როცა თავად VPN ჯანმრთელად გამოიყურება.
ჩაწერეთ აუზის დიაპაზონი, ყოველი დამაგრებული მისამართი და მისი მფლობელი ჰოსტი სერვერის ჩანაწერებში. მაშინ შემდეგი შეჯახება წუთებში შესამჩნევი იქნება, ნახევარი დღის ხელახლა აღმოჩენის ნაცვლად.