პროდუქტის VPN კლიენტად წოდება არაფერს ამბობს იმაზე, ლაპარაკობს თუ არა ის SSTP-ზე, ხოლო მისამართში პორტი 443 კიდევ ნაკლებს ამტკიცებს. SSTP ატარებს TLS-ს TCP 443-ზე, შემდეგ SSTP საკონტროლო გაცვლას, შემდეგ PPP-ს თავად კავშირისთვის, ზემოდან კი სერტიფიკატის ვალიდაცია და PPP ავთენტიფიკაციის მეთოდი. კლიენტი პროტოკოლს მხარს მხოლოდ მაშინ უჭერს, როცა დასახელებული იმპლემენტაცია, დაყენებულ ვერსიაში, ასრულებს თითოეულ ამ ფენას თქვენი სერვერის მოთხოვნების მიხედვით. შეასრულეთ ქვემოთ მოცემული შემოწმებები თანმიმდევრობით და გაჩერდით პირველ წარუმატებელზე, რადგან სწორედ ის ღირს გადაჭრად.

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

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

Windows-ში გვირაბის ტიპი პლატფორმიდან მოდის და არა GUI-დან, ამიტომ ჰკითხეთ პლატფორმას. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress აჩვენებს Sstp-ს, როცა მშობლიური კლიენტი პროტოკოლს სცდის, ხოლო კავშირის ტიპების ცნობარი მას ჩაშენებულ გვირაბის ტიპებში ჩამოთვლის. Linux-ში მშობლიური SSTP კლიენტი საერთოდ არ არსებობს, ამიტომ კითხვა ხდება, დაყენებული და აქტუალურია თუ არა ცალკე იმპლემენტაცია, მაგალითად sstpc sstp-client პაკეტიდან.

წაიკითხეთ პროფილის ფორმატი იარლიყამდე

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

თუ ფაილი .ovpn ან WireGuard კონფიგურაციაა, პასუხი უკვე ნათელია: ამ კლიენტს SSTP-ზე ლაპარაკი არ მოსთხოვეს. მხოლოდ SSTP-ის მქონე კლიენტში იმპორტი პროფილის ეტაპზევე ცდება, პროტოკოლის ნებისმიერ მოლაპარაკებამდე დიდი ხნით ადრე.

რასაც TLS არ ამტკიცებს განლაგების შესახებ

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

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

თვალი ადევნეთ სესიას ოთხ ეტაპზე

ნახეთ, როგორ კვეთს კავშირი ოთხ საზღვარს: TCP და TLS სერვერამდე, SSTP საკონტროლო გაცვლა, PPP მოლაპარაკება და შემდეგ ის რესურსი, რომელიც ნამდვილად გჭირდებათ. ჟურნალი, რომელიც TLS-ის შემდეგ ჩერდება, სხვა ხარვეზს აღწერს, ვიდრე PPP-ის შიგნით ჩამდგარი, და ორივე სხვადასხვა პასუხისმგებელთან მიდის. ბრაუზერში ჰოსტის ვებ გვერდის ჩატვირთვა მხოლოდ იმას ამტკიცებს, რომ 443-ზე რაღაცამ უპასუხა, რაც ამ სფეროში ყველაზე გავრცელებული ცრუ დადებითია. თუ ეს გვერდი იტვირთება, კლიენტი კი კვლავ ცდება, პრობლემა TLS-ის ზემოთაა და ვებ სერვერი ეჭვმიტანილი არ არის.

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

როცა მხარდაჭერა აკლია, შეცვალეთ გეგმა

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

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

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