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

ავთენტიფიკაცია გვირაბის შიგნით მიდის

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

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

სამი ადგილი, სადაც იგივე მეთოდი ჩნდება

PPP-ში ავთენტიფიკაციის საფეხური ელოდება, სანამ კავშირი არსებობს, და RFC 2759 MS-CHAPv2-ს სწორედ ამ საფეხურად განსაზღვრავს, ამიტომ მეთოდი ჩნდება L2TP და უფრო ძველ PPTP განლაგებებში. გვირაბი პირველი სრულდება და PPP მოლაპარაკება მის შიგნით ხდება, ასე რომ წარუმატებელ PPP ეტაპს შეუძლია სერვერის ჟურნალში გვირაბი დადგენილად დატოვოს. წაიკითხეთ ეს ორი ეტაპი ცალ-ცალკე, სანამ დაასკვნით, რომ სერტიფიკატები უარყოფილია. ამრიგად, L2TP-სთვის კონფიგურირებული კლიენტი შეიძლება სრულიად სწორი იყოს და მაინც იყოს არასწორი კლიენტი იმ კარიბჭისთვის, რომელიც მხოლოდ IKEv2-ს ლაპარაკობს.

IKEv2 სამაგიეროდ EAP-MSCHAPv2-ს გასაღების გაცვლის შიგნით ათავსებს, ასე რომ იგივე სერტიფიკატი სხვა მომენტში ჩავარდება და ავთენტიფიკაციის შეცდომად ჩნდება, და არა სესიის შეცდომად. Android-ის პლატფორმული IKEv2 პროფილი ყოველდღიური მაგალითია და ის PPP ოპციების ნაცვლად სერვერის სერტიფიკატს ან იდენტიფიკატორს ითხოვს. ანგარიშის სახელი ორივე კონფიგურაციაში იდენტურია, ამიტომ ვერ გეტყვით, რომელი გაქვთ. ამას მხოლოდ ოპერატორის მხარდაჭერილი პროტოკოლების სია წყვეტს.

TLS-ზე დაფუძნებული VPN მესამე კონფიგურაციას ამატებს, საკუთარი მომხმარებლის სახელისა და პაროლის ველებით და გაცვლაში არსად MS-CHAPv2-ის გარეშე. ამიტომ პაროლის ველის დანახვა მის უკან მდგარი პროტოკოლის მტკიცებულება არ არის, რადგან ფორმა ნაცნობად რომ გამოიყურებოდეს, ისეა აწყობილი. დაადასტურეთ პროტოკოლი სერვერის დოკუმენტაციიდან და არა კლიენტის ფანჯრის ფორმიდან.

პასუხები, რომლებიც ნამდვილად გჭირდებათ

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

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

What you ask forIf it is wrong, the symptom shows up as
Tunnel protocolNo profile can be built at all
Method inside the tunnelCredentials typed, then rejected
Gateway identityThe client refuses the server certificate
Account formatAuthentication fails only for some staff
Routes and DNSThe tunnel is up and nothing resolves

ნუ შეასუსტებთ კარიბჭის შემოწმებას

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

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

მოარგეთ პროფილი, შემდეგ დაამტკიცეთ ყოველი ეტაპი

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

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

დაკავშირებული სტატიები