L2TP პროფილის რომელი დონე რეალურად გატყდა

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

პროტოკოლის იგივე სახელი ოთხ სხვადასხვა საუბარს მალავს.

დაასახელეთ დონე, სანამ პარამეტრებს შეცვლით

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

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

შეადარეთ პროფილი მიმდინარე კლიენტს

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

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

ძველი პარამეტრები არ ბრუნდება ჩართვით

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

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

წარმოადგინეთ მიგრაცია როგორც პროექტი

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

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

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