OpenConnect-ის შესვლა არასწორ გვერდზე ხვდება? ჯერ ბილიკი შეამოწმეთ

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

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

რას აგზავნის კლიენტი ფორმის დანახვამდე

https://vpn.example.net/partners მსგავსი მისამართით კლიენტის პირველი ქმედება HTTPS მოთხოვნაა ამ ბილიკზე და არა შიშველ ჰოსტზე. უკან ჩვეულებრივ მოდის გადამისამართება შესვლის ბოლო წერტილზე, ან თავად ფორმა. მხოლოდ vpn.example.net-ის მიმღები კლიენტი იწყებს იმ ნაგულისხმევ სადესანტო გვერდიდან, რომელიც არსებობს, და ეს შეიძლება იყოს სხვა პორტალი, სხვა ჯგუფების სია ან გვერდი, რომელიც სრულიად სხვა პროტოკოლს ელოდება. განსხვავება პასუხის სათაურებში ჩანს გაცილებით ადრე, ვიდრე რომელიმე სერტიფიკატი ჩაიწერება.

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

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

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

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

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

რატომ ცვლის ბილიკის შეჭრა შედეგს

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

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

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

სანამ სხვა რამეს შეცვლით, შესასვლელი წერტილი დაადასტურეთ

წაიკითხეთ სათაურები იმ ბილიკისთვის, რომელიც მოგცეს. curl -sS -o /dev/null -D - https://vpn.example.net/partners-ის მსგავსი მოთხოვნა ბეჭდავს სტატუსის სტრიქონს და ნებისმიერ Location სათაურს გადამისამართების მიუყოლებლად. დასახელებულ შესვლის ბოლო წერტილზე მიმითითებელი 302 ადასტურებს, რომ ბილიკი არსებობს და აჩვენებს, სად მიდის; 404 ნიშნავს, რომ ოპერატორის მისამართი მოძველებულია.

შემდეგ იგივე შესასვლელი წერტილი გაამრავლეთ დამტკიცებულ კლიენტში, მაგალითად openconnect --usergroup=partners vpn.example.net, და დააკვირდით, რომელი ფორმა გამოჩნდება. თუ ფორმა სწორია და გვირაბი მაინც ვერ მუშაობს, ბილიკი არასდროს ყოფილა პრობლემა და შემდეგი გაჩერება პოლიტიკა ან მარშრუტიზაციაა.

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