OpenVPN HTTP პროქსის მეშვეობით: ჯერ CONNECT-ის პასუხი წაიკითხეთ
CONNECT პროქსი ბაიტებს გადასცემს, ამიტომ ორივე მხარეს TCP სჭირდება. სერტიფიკატების დადანაშაულებამდე წაიკითხეთ 407, 403 და 503, და დატოვეთ სერვერის შემოწმება ჩართული.
მიმართეთ VPN კლიენტი კორპორატიულ HTTP პროქსიზე, და პირველი სასარგებლო ფაქტი ის არის, რომ პროქსი VPN-ის პროტოკოლზე არ ლაპარაკობს. ის ხსნის ჩვეულებრივ TCP კავშირს თქვენს მიერ დასახელებულ მისამართზე და შემდეგ გვერდზე უხვევს, რითაც კლიენტი და სერვერი საკუთარ გაცვლას ამ ნაკადში აწარმოებენ. ყველაფერი, რაც კლიენტს სჭირდება, ტრანსპორტის ტიპიდან სერვერის მსმენელამდე, ამ განლაგებას უნდა შეესაბამებოდეს. ორი შეუსაბამობა ხსნის წარუმატებლობების უმეტესობას: UDP პროფილი, რომელიც CONNECT პროქსიზეა მიმართული, და პროქსის პასუხი, რომელიც შეცდომით VPN-ის შეცდომად მიიღება.
რას ატარებს პროქსი და რას არა
პროქსი მხოლოდ ტრანსპორტის საფეხურია. ის არ ხდება თქვენი ბრაუზერის პროქსი, არ ინახავს ქეშში იმ საიტებს, რომლებსაც გვირაბით სტუმრობთ, და არ ხედავს შიდა ტრაფიკს, თუ ვინმემ განზრახ არ დააყენა შემოწმება. გვირაბი, რომელსაც ის ხსნის, დიზაინით მისთვის გაუმჭვირვალეა.
ეს ასევე ნიშნავს, რომ პროქსი ვერ შეაკეთებს სერვერს, რომელსაც შესაბამისი მსმენელი არ აქვს. დანიშნულების მიღწევის ნებართვა და ამ დანიშნულებაზე მოსმენილი სერვისი ორი ცალკე ფაქტია, და მხოლოდ პირველი ეკუთვნის პროქსის ადმინისტრატორს.
გადამტანი ორივე ბოლოში TCP უნდა იყოს
ჩვეულებრივი CONNECT პროქსი მხოლოდ ბაიტების ნაკადს გადასცემს , ამიტომ კლიენტმა ნაკადური ტრანსპორტი უნდა გამოიყენოს. კლიენტის ფრაგმენტი ამ შემთხვევისთვის ასე გამოიყურება:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128სერვერის მხარეს ნამდვილი TCP მსმენელი სჭირდება remote ხაზში დასახელებულ პორტზე. პროფილში proto udp-ის proto tcp-client-ით შეცვლა ქმნის კლიენტს, რომელიც ნაკადს ელოდება; ის არ ქმნის ნაკადს მეორე მხარეს. თუ იმავე სერვერი ამ პორტზე UDP-ითაც პასუხობს, ეს სხვა მსმენელია, და არა იმავეს მეორე რეჟიმი.
სადაც ცალკე TCP ინსტანცია არსებობს, მისი გვირაბის მოწყობილობა, მისამართების აუზი და მარშრუტიზაცია საკუთარი რესურსებია. მომუშავე კონფიგურაციის კოპირება და ტრანსპორტის სიტყვის შეცვლა ამ რესურსებს საწყის ინსტანციაზე მიმართულს ტოვებს, რაც ქმნის კავშირს, რომელიც ავთენტიფიცირდება და შემდეგ არაფერს მარშრუტიზაციას უკეთებს.
წაიკითხეთ პროქსის პასუხი VPN-ის შედეგამდე
კლიენტის პირველი გაცვლა მოთხოვნის ხაზია, რომელიც დანიშნულების ჰოსტს და პორტს ასახელებს. ამ ხაზზე პასუხი გეუბნებათ, საერთოდ არსებობს თუ არა ბაიტების ნაკადი, და ის ნებისმიერი სერტიფიკატის ან სამოწმებელი მონაცემის შემოწმებამდე მოდის:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT-ზე 200 კლასის პასუხი ნიშნავს, რომ ნაკადი არსებობს. ის არაფერს ამბობს იმაზე, სანდოა თუ არა კარიბჭის სერტიფიკატი, ემთხვევა თუ არა საერთო გასაღები, ან მოქმედია თუ არა მომხმარებლის ანგარიში. ეს შემოწმებები შემდეგ ხდება, ნაკადის შიგნით, და ისინი მარცხდება კლიენტის საკუთარი შეტყობინებებით და არა HTTP სტატუსის ხაზით. კლიენტის ჟურნალში მოძებნეთ პირველი OpenVPN მოვლენა პროქსის ხელის ჩამორთმევის შემდეგ, და არა ბოლო ხაზი ფანჯრის დახურვამდე.
პროქსის და VPN-ის სამოწმებელი მონაცემები ხშირად სხვადასხვა იდენტობაა სხვადასხვა გუნდის ხელში. 407 არ არის VPN ანგარიშის ცუდი პაროლი, და უარყოფილი სერტიფიკატი არ არის პროქსის ნებართვის პრობლემა.
რას არ ამჟღავნებს CONNECT
გამოკვეთილი CONNECT გვირაბი ჩარევა არ არის. პროქსი ბაიტებს გადასცემს და არ ამთავრებს VPN-ის TLS სესიას, ამიტომ სერვერის სერტიფიკატის კლიენტისეული შემოწმება მნიშვნელოვანი რჩება და ჩართული უნდა დარჩეს. შემოწმების გამორთვა პროქსის გასავლელად თქვენისგან განსხვავებულ პრობლემას წყვეტს.
არსებობს ცალკე მოწყობები, სადაც ორგანიზაცია განზრახ ამთავრებს და ამოწმებს TLS-ს. ისინი საკუთარ ნდობის კონფიგურაციას და საკუთარ პოლიტიკურ გადაწყვეტილებას მოითხოვენ, და ისინი არ არიან ის, რასაც ჩვეულებრივი http-proxy ხაზი ითხოვს.
TCP-ის ფასი TCP-ის შიგნით
გვირაბის TCP-ზე გადატანა გარე ნაკადს მოწესრიგებულ და განმეორებით გაგზავნილს ინახავს, და შიდა ტრაფიკიც ჩვეულებრივ TCP-ია. ორი აღდგენის მექანიზმი არ კოორდინირდება, ამიტომ ერთმა დაკარგულმა სეგმენტმა შეიძლება გააჩეროს ყველაფერი, რაც ამ გარე ნაკადს იზიარებს, სანამ ის ხელახლა არ გაიგზავნება. ეს თავსებადობისთვის რეალური გაცვლაა და არა უფასო გაუმჯობესება.
გამოიყენეთ პროქსის გზა, როცა ქსელი ალტერნატივას არ გიტოვებთ, და ამჯობინეთ პირდაპირი UDP გზა იქ, სადაც პოლიტიკა იძლევა. ყოველ შემთხვევაში, ცვლილების შემდეგ დაადასტურეთ, რომ იგივე პროქსი, დანიშნულება და პროფილი შემდეგ ეტაპს აღწევს; ბრაუზერი, რომელიც ამ მისამართზე გვერდს ტვირთავს, სხვა პროტოკოლს იყენებს და გვირაბზე არაფერს ამტკიცებს.