სერვერზე ჩაკეტილი პროფილი მარცხდება TLS პროქსის უკან: რომელი თაობა?
Access Server 2.8 და 2.9 სერვერზე ჩაკეტილ პროფილებს სხვადასხვაგვარად ქმნიან. გადაწყვიტეთ, რომელ გზას ამტვრევს თქვენი პროქსი, სანამ წინა ნაწილს შეცვლით.
ერთი მომხმარებელი უერთდება, მეორე კი არა, იმავე პორტალით, იმავე დღეს. ორივეს აქვს სერვერზე ჩაკეტილი პროფილი, ორივე იმავე Access Server-ის ნაგებობაზეა, და ერთადერთი განსხვავება ის არის, როდის შეიქმნა მათი პროფილი. ეს არის ის ნიმუში, რომლის ამოცნობაც ღირს, რადგან "სერვერზე ჩაკეტილი" პოლიტიკას აღნიშნავს და არა დაკავშირების თანმიმდევრობას. Access Server-მა ამ არტეფაქტის ორი თაობა გამოუშვა, და TLS საპირისპირო პროქსი მათი მხოლოდ ერთი გზის წინ დგას. სამი პირობა განსაზღვრავს, რომელ ტოტში ხართ.
ორი თაობა, დაკავშირების ორი თანმიმდევრობა
ძველ დიზაინში, რომელიც 2.8-მდე მოქმედებს, იმპორტირებული ფაილი ფსევდო პროფილია. OpenVPN Connect იყენებს მას HTTPS-ით Access Server-ის ვებ API-ს წინაშე ავთენტიფიკაციისთვის, იღებს დროებით მომხმარებელზე ჩაკეტილ პროფილს და სესიის ტოკენს, და მხოლოდ ამის შემდეგ ამყარებს VPN-ს. ორი ტრანსპორტი თანმიმდევრულად მუშაობს, და პირველი ჩვეულებრივი ვებ მოთხოვნაა.
2.9-თან დანერგილი ფორმატი ამ დაკავშირებაზე დაფუძნებულ საწყის ჩატვირთვას არ ასრულებს. ეს არის მშობლიური პროფილი, რომლის გამოყენებაც შეუძლიათ თავსებად OpenVPN კლიენტებს, და არა მხოლოდ OpenVPN Connect-ს. მისი ჩამოტვირთვა ან URL-ით იმპორტი მაინც შეიძლება მოიცავდეს HTTPS-ს — ეს გამოქვეყნების ნაბიჯია და არა დროებითი პროფილის მიღება ყოველ დაკავშირებაზე.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
განახლება სულაც არ გადაწერს უკვე გაცემულ პროფილებს, ამიტომ მიმდინარე სერვერის ვერსია შეიძლება ჯერ კიდევ ძველ არტეფაქტს ავრცელებდეს. სერვერის ნაგებობა გეუბნებათ, რა არის შესაძლებელი და არა რა იმპორტირებული აქვს ამ მომხმარებელს.
სამი პირობა, რომლებიც ირჩევენ თქვენს ტოტს
პირველი პირობა არტეფაქტის თაობაა. მოითხოვეთ ფაილი, ნახეთ როგორ შეიქმნა, და ჩაიწერეთ იმ კლიენტის ვერსია, რომელმაც ის იმპორტირა. თუ თაობას ფაილიდან ვერ დაადგენთ, ტესტური ანგარიშისთვის გაცემული ახალი პროფილი გეტყვით, რას აწარმოებს სერვერი დღეს, და ეს სხვა ინფორმაციაა, ვიდრე ის, რაც წარუმატებელ მომხმარებელს აქვს.
მეორე ის არის, რას ასრულებს თქვენი წინა ნაწილი რეალურად. მეშვიდე დონის HTTP საპირისპირო პროქსი, რომელიც TLS-ს ხსნის, არ არის იგივე ობიექტი, რაც მეოთხე დონის TCP გამტარი, და UDP გამტარიც არა. Access Server-ის ჩვეულებრივი განლაგება 443 პორტზე OpenVPN TCP დემონს აიძულებს ბრაუზერის ტრაფიკი ამოიცნოს და ვებ სერვისებს გადასცეს, ამიტომ წინ უცხო HTTPS დამამთავრებლის ჩასმა ამ დემონის პროტოკოლის დამუშავებას არ ინარჩუნებს. 443 რიცხვის გაზიარება ორ დიზაინს ეკვივალენტურს არ ხდის.
მესამე ის არის, სად ეცემა მარცხი. VPN-მდე მარცხი და საკონტროლო არხის მარცხი მსგავსად გამოიყურება კლიენტში, რომელიც მხოლოდ "უკავშირდება"-ს ამბობს, მაგრამ კვალს სხვადასხვა ადგილას ტოვებენ. თუ ძველი ფორმატი მოქმედებს, საწყისი ჩატვირთვა კანდიდატია. თუ ახალი ფორმატი მოქმედებს, ცარიელი ვებ წვდომის ჟურნალი მოსალოდნელია და არაფერს ამტკიცებს არც ერთი მიმართულებით.
როცა არტეფაქტი ძველია: საწყისი ჩატვირთვა პირველი მარცხდება
წაიკითხეთ კლიენტის ფაქტობრივი შეცდომა და არა მისი საბოლოო მდგომარეობა. საინტერესო ველებია HTTPS შეცდომა, სერვერის ის იდენტობა, რომელსაც კლიენტი ელოდა, დანიშნულება სადაც მოთხოვნა წავიდა, და დასრულდა თუ არა სერტიფიკატის ვალიდაცია. შემდეგ შეადარეთ ისინი სერვერის მხარეს ვებ სერვისისა და პროქსის ჟურნალებს.
ბრაუზერის შესვლის გვერდზე მისვლა არ არის მტკიცებულება, რომ ამ კლიენტის API ავთენტიფიკაცია წარმატებით დასრულდა. ეს სხვადასხვა მოთხოვნებია, სხვადასხვა სერტიფიკატის მოლოდინით და ხშირად სხვადასხვა ჰოსტის სახელით. თუ პორტალი სწორად მოემსახურება და კლიენტი მაინც მარცხდება, უთანხმოება საწყისი ჩატვირთვის გზაშია და არა მომხმარებლის პაროლში.
ნუ მიაღწევთ შედარების გავლას TLS ვერიფიკაციის გამორთვით ან ავთენტიფიკაციის პოლიტიკის შესუსტებით. ეს დიაგნოსტირებად კონფიგურაციის შეუთავსებლობას აქცევს მომუშავე, მაგრამ დაუდასტურებელ გზად, და სწორედ ეს ცვლილება აქცევს დროებით ტესტს მუდმივ ხვრელად. Access Server-ის დაკავშირების პროფილების დოკუმენტაცია აღწერს ორივე თაობას და დროებითი პროფილის დინებას, და ეს არის ის ცნობარი, რომელიც უნდა შეამოწმოთ სანამ პროქსის დაადანაშაულებთ.
როცა არტეფაქტი ახალია: წაიკითხეთ საკონტროლო არხი
2.9 სტილის პროფილით კლიენტი პირდაპირ VPN-ის მშობლიურ საბოლოო წერტილზე მიდის. გამოიკვლიეთ პროფილში არსებული საბოლოო წერტილები, გამოყენებული ტრანსპორტი და საკონტროლო არხის შეცდომა. თუ კლიენტი არასოდეს აგზავნის HTTP მოთხოვნას, ეს დიზაინს შეესაბამება და სიმპტომი არ არის.
აქვე იცვლის ფორმას პროქსის კითხვაც. HTTPS განტვირთვა ვერ დაამტვრევს მხოლოდ TCP ნაკადს, რომელსაც არასოდეს ხედავს, მაგრამ მაინც შეიძლება დაამტვრიოს ჩამოტვირთვა, რომელიც პროფილს აქვეყნებს, და მხოლოდ TCP გამტარი UDP-ს საერთოდ არ გადაიტანს. შეამოწმეთ რომელ ტრანსპორტს ითხოვს პროფილი, სანამ დაასკვნით, რომ წინა ნაწილი უმნიშვნელოა.
TLS-ის გატარება ერთი ნაკადისთვის ვიწრო განლაგებაა. ის არ უზრუნველყოფს UDP გადაცემას და არ ამრავლებს დემონის საკუთარ სერვისების გადაცემის ქცევას 443-ზე. თუ თქვენი წინა ნაწილი ერთ-ერთს აკეთებს, მიუთითეთ რომელს, რადგან მკურნალობა განსხვავებულია.
მკურნალობები, რომლებიც ვიწროდ რჩება
ყველაზე ნაკლებად ჩამრევი შემოწმებაა ტესტური ანგარიშისთვის ახალი მხარდაჭერილი პროფილის შექმნა და განკუთვნილ მშობლიურ საბოლოო წერტილზე იმავე ავთენტიფიკაციის მოთხოვნებით დაკავშირება. თუ ეს მუშაობს და შენახული ძველი პროფილი არა, თქვენ ერთ ნაბიჯში გამოყავით არტეფაქტი სერვერისგან და პროქსისგან.
მომხმარებელზე ჩაკეტილი პროფილის გავრცელება მთლიანად აშორებს ძველი საწყისი ჩატვირთვის დამოკიდებულებას, რადგან არ არსებობს დროებითი პროფილის გაცვლა, რომელიც შეიძლება ჩავარდეს. ის უნდა გაიცეს განკუთვნილ მომხმარებელზე, არასოდეს დაკოპირდეს ადმინისტრატორისგან, და ის ცვლის რისი უფლებაც კლიენტს აქვს, ამიტომ მოეკიდეთ როგორც პოლიტიკის გადაწყვეტილებას და არა როგორც შემოვლით გზას.
შემდეგ გაასწორეთ გამოქვეყნების განლაგება ისე, რომ ყოველი საჭირო გზა არსებობდეს: ვებ გზა ჩამოტვირთვებისა და პორტალის გამოყენებისთვის, და მშობლიური VPN გზა იმ ტრანსპორტზე, რომელსაც პროფილები ელიან. შეინარჩუნეთ პროქსის სამუშაო ერთ დონეზე. მომუშავე მომხმარებელზე ჩაკეტილი გვირაბი ამტკიცებს, რომ ეს გზა მუშაობს; ის არ ამტკიცებს, რომ ყოველი პროქსის განლაგება ყოველ თაობას უჭერს მხარს, და ძველი საწყისი ჩატვირთვის მარცხი არ განსჯის უფრო ახალ ფორმატს.
- განსაზღვრეთ არტეფაქტის თაობა სანამ პროქსის შეეხებით.
- დაადგინეთ მარცხი გვირაბამდე ხდება თუ მის შიგნით.
- დაადასტურეთ რას ასრულებს წინა ნაწილი: HTTP, TCP ნაკადი თუ UDP.
- შეამოწმეთ ახლად გაცემული პროფილი მშობლიურ საბოლოო წერტილთან პოლიტიკის უცვლელად.