VPN იწყვეტს DHCP განახლების შემდეგ? შეადარეთ მისამართები
განახლება ჩვეულებრივ იმავე მისამართს ინარჩუნებს. სანამ იჯარას დაადანაშაულებთ, გადახედეთ კლიენტის მისამართს, კარიბჭეს, ამომხსნელს და მარშრუტის მდგომარეობას გაწყვეტის ირგვლივ.
იჯარის განახლება და VPN-ის გაუმართაობა საკმარისად ხშირად ერთად ჩნდება ჟურნალებში, რომ ადამიანები ასკვნიან, ერთი მეორეს იწვევსო. დროითი დამთხვევა რეალურია; მიზეზობრიობა ჩვეულებრივ არა. განახლება არის უნიკასტური მოთხოვნა იმ სერვერზე, რომელმაც გასცა იჯარა, იმავე მიბმულობის გაგრძელების თხოვნით, და სერვერს შეუძლია გაახანგრძლივოს ის კლიენტის მიერ ერთი მისამართის შეუცვლელად. მოვლენის ირგვლივ კლიენტის საკუთარი მნიშვნელობების განხილვა ჰყოფს ჩუმად განახლებულ იჯარას იმ ქსელისგან, რომელიც მართლაც შეიცვალა მოქმედი გვირაბის ქვეშ.
დაიწყეთ იმ კლიენტით, რომელიც გაწყდა
ჯერ გახსენით კლიენტის კავშირის ჟურნალი და ჩაწერეთ გაწყვეტის დრო წამამდე. შემდეგ გახსენით ოპერაციული სისტემის ქსელის ჟურნალი იმავე წუთისთვის და თანმიმდევრობით წაიკითხეთ, რა გააკეთა ინტერფეისმა. ეს თანმიმდევრობა მთელი გამოძიებაა: DHCP მოვლენა გათიშვამდე, გათიშვა DHCP მოვლენამდე და ორი მოვლენა, რომელთა შორისაც არაფერია, სამი განსხვავებული აღმოჩენაა. ჟურნალის ის სტრიქონი, რომელიც მხოლოდ იჯარას იხსენიებს, სანამ გვირაბი უკვე ხელახლა უკავშირდებოდა, მორთულობაა და არა მტკიცებულება.
დაწერეთ დროის ხაზი მიდის-მიდის, ნაცვლად იმისა რომ მეხსიერებაში შეინახოთ. სხვადასხვა ხელსაწყოს დროის ნიშნები იშვიათად ემთხვევა სრულყოფილად, და თვით გადახრა ზოგჯერ განმარტებაა.
შეადარეთ ოთხი მნიშვნელობა მოვლენის ირგვლივ
ოთხი მნიშვნელობა საკმარისად კარგად აღწერს კავშირის ლოკალურ მხარეს რეალური ცვლილების დასაფიქსირებლად: ინტერფეისის მისამართი, ნაგულისხმევი კარიბჭე, ამომხსნელების სია და ინტერფეისის მუშაობის მდგომარეობა. აიღეთ ისინი გაწყვეტიდან ერთი წუთის განმავლობაში და შეადარეთ ჩანაწერს, რომელიც გაკეთდა გვირაბის ჯანსაღ მდგომარეობაში.
ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp
უცვლელი მისამართი უცვლელი კარიბჭით და შეცვლილი ამომხსნელების სიით სახელების ამოხსნაზე მიუთითებს და არა მარშრუტიზაციაზე, და გვირაბი შეიძლება გადარჩა მაშინ, როცა აპლიკაციებმა ჰოსტების პოვნა შეწყვიტეს. შეცვლილი კარიბჭე ნიშნავს, რომ ლოკალური ქსელიდან გასასვლელი გზა გადაადგილდა, და ეს საკმარისია წინაზე მიმთითებელი მარშრუტის გასაუქმებლად. თუ ოთხივე მნიშვნელობა ემთხვევა ჯანსაღ ჩანაწერს, იჯარა თქვენი მიზეზი არ არის და თემად კლიენტის საკუთარი ხელახლა დაკავშირების ლოგიკა იქცევა. აიღეთ შედარება მაშინ, როცა ხარვეზი ჩანს, რადგან ხელახალი ჩატვირთვის შემდეგ გაკეთებულ ჯანსაღ ჩანაწერს სხვა მისამართების ისტორია აქვს და არ დაემთხვევა.
რა შეიძლება და რა არ შეიძლება შეცვალოს განახლებამ
RFC 2131 განახლებას აღწერს როგორც მოთხოვნას საწყის სერვერზე იჯარის ვადის ნახევარზე, ნებისმიერ სერვერზე ხელახალი მიბმით რვიდან შვიდ ნაწილზე, თუ პირველი ცდა უპასუხოდ დარჩა. არც ერთი ნაბიჯი არ მოითხოვს, რომ კლიენტმა სხვა მისამართი მიიღოს, და თანამშრომლობითი სერვერი ჩვეულებრივ ახანგრძლივებს არსებულ მიბმულობას. მისამართის რეალური ცვლილება ჩვეულებრივ სხვა გზით მოდის: სერვერი უარყოფს განახლებას, კლიენტმა დაკარგა თავისი მდგომარეობა და თავიდან დაიწყო, ან ქსელმა მოწყობილობა სხვა სეგმენტზე გადაიტანა.
კავშირის საჯარო მხარე შეიძლება შეიცვალოს ყოველგვარი ლოკალური ცვლილების გარეშე. ოპერატორული დონის თარგმანის მიღმა, მისამართი, რომელსაც VPN-ის პარტნიორი ხედავს, შეიძლება ხელახლა გამოიყოს ლოკალური იჯარის მოქმედებისგან დამოუკიდებლად, და ეს ხელახალი განაწილება კლიენტის შიგნიდან ლოკალური ქსელის ხარვეზის იდენტურად გამოიყურება. ლოკალურად მოხსენებული მისამართის პარტნიორის მხრიდან დაკვირვებასთან შედარება მათი გამიჯვნის ერთადერთი გზაა.
როცა კლიენტი ვერ ეგუება
კლიენტი, რომელმაც ტრანსპორტი ძველ მისამართზე მიაკრა, პარტნიორისკენ მოძველებული მარშრუტი დააქეშა ან ინტერფეისის იდენტობა შეინახა, შეიძლება განაგრძოს იმ გზის ცდა, რომელიც აღარ არსებობს. ეს ადაპტაციის ნაკლია და ჩანს როგორც განმეორებითი ხელახალი გადაცემები იმ მისამართისკენ, რომელსაც ჰოსტი ვეღარ აღწევს. ზოგი კლიენტი ამას დიზაინით აგვარებს: მაგალითად, WireGuard აახლებს პარტნიორის ბოლო წერტილს, როცა სწორად აუთენტიფიცირებული პაკეტი ახალი წყაროდან მოდის.
სერვისის აღმდგენი ხელით გადატვირთვა მინიშნებაა იმაზე, სად წარმატებით ვერ მოხდა ადაპტაცია, და არა მტკიცებულება იმისა, რომ იჯარები და გვირაბები შეუთავსებელია. ტესტირების დროს დატოვეთ ბლოკირების პოლიტიკა ძალაში, თორემ თავად ტესტი სხვა მიზეზის მქონე შეფერხებად იქცევა. ჩაწერეთ, აღდგა თუ არა კლიენტი თავისით, რამდენი ხანი დასჭირდა და რომელ მისამართს სცადა ისევ; ეს თანმიმდევრობა უფრო მეტს გითხრობთ, ვიდრე ინტერფეისში ნაჩვენები გაწყვეტის მიზეზი.
სანამ დაადანაშაულებთ, გაიმეორეთ მოვლენა
გაამრავლეთ პირობა ნაცვლად გრაფიკის ლოდინისა: გაათავისუფლეთ და განაახლეთ იჯარა, ან აიძულეთ ექვივალენტური კონტროლირებული მოვლენა, და დააკვირდით, გადარჩება თუ არა გვირაბი. მართულ ქსელში ნებისმიერი მისამართის ცვლილება შეათანხმეთ ქსელის მფლობელთან, რადგან თვითნებური სტატიკური მინიჭება შეიძლება დაეჯახოს მოწყობილობას, რომელსაც ეს მისამართი უკვე აქვს.
მხარდაჭერილი შესწორების შემდეგ გაიმეორეთ იგივე მოვლენა და შემდეგ შეამოწმეთ აპლიკაცია და სახელის მოთხოვნა, რადგან გვირაბი, რომელიც ხელახლა უკავშირდება, მაგრამ DNS-ს ამტვრევს, უფრო სუსტ ტესტს გადის, ვიდრე ის, რაც მნიშვნელოვანია. მოახსენეთ თქვენ მიერ დაკვირვებული კონკრეტული ცვლილება მისი დროის ნიშნით, ნაცვლად იმისა რომ დაგეგმილი იჯარა მიზეზად დაასახელოთ. ამ ორ მოხსენებას შორის განსხვავება ისაა, შეძლებს თუ არა შემდეგი ადამიანი ხარვეზის გამრავლებას თუ მხოლოდ ჭორის.