SOCKS5 პროქსი OpenVPN-ისთვის: TCP გვირაბი თუ აპების პროქსირება?

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

ერთი შეზღუდვა წყვეტს დიზაინს

SOCKS5 ნამდვილად განსაზღვრავს UDP ასოციაციის რეჟიმს. მიუხედავად ამისა, OpenVPN კლიენტის პროქსის მხარდაჭერა ნაკადების გარშემოა აგებული: socks-proxy დოკუმენტირებულია TCP პროფილებისთვის, და HTTP CONNECT პროქსს საერთოდ არ აქვს გზა დატაგრამებისთვის. დოკუმენტაციის ერთი ხაზი წყვეტს არქიტექტურას, სანამ კონფიგურაციის ფაილს შეეხებით.

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

ვარიანტი A: გვირაბი ნაკადად აქციეთ

ეს მოითხოვს სერვერს TCP მსმენელით და კლიენტის პროფილს, რომელიც პროქსს ასახელებს. ორივე ნაწილი აუცილებელია, და სერვერის მხარეა ის, რასაც ხალხი ივიწყებს:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

შეცვალეთ ბოლო ხაზი http-proxy proxy.internal 8080-ით, როცა პროქსი HTTP-ზე საუბრობს, და დაამატეთ სერტიფიკატების ფაილი, თუ მას ითხოვს. პროქსი უნდა იყოს მზად CONNECT-ის შესასრულებლად თქვენს VPN პორტზე, და სერვერმა უნდა უპასუხოს TCP-ით; მხოლოდ UDP მსმენელი უგულებელყოფს მცდელობას. 443-ის არჩევა პრაქტიკული ნაბიჯია, რადგან ბევრი შემზღუდავი ქსელი იძლევა ამის და ცოტა სხვა რამის ნებას.

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

ვარიანტი B: გვირაბს მარტო დაუტოვეთ

როცა გვირაბი UDP-ზე უნდა დარჩეს, გვირაბი არ არის ადგილი, სადაც რამეს აკონფიგურირებთ. სამაგიეროდ, აპლიკაციებიდან გამავალი TCP გადამისამართდება ლოკალურ SOCKS მსმენელზე, და აპლიკაციები ვერასოდეს გაიგებენ, რომ პროქსი არსებობს. Linux-ზე ეს ჩვეულებრივ redsocks არის, nat ცხრილში NAT REDIRECT წესის დამატებით.

ისევ მხოლოდ TCP. მხოლოდ HTTP პროქსი, როგორიც privoxy-ა, ვერ გადასცემს თვითნებურ პროტოკოლებს, და ეს დიზაინი აპლიკაციებისთვის დატაგრამის მხარდაჭერასაც არ ამატებს.

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

სად იშლება თითოეული ვარიანტი

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

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

არც ერთი ვარიანტი არ ცვლის მოწყობილობის მოთხოვნას. პაკეტებს კვლავ სჭირდება TUN ან TAP კვანძი, სანამ ბირთვი მათ მარშრუტიზაციას მოახდენს, ამიტომ პროცესს კვლავ სჭირდება ნებართვა /dev/net/tun-ზე. გარსი ცვლის იმას, რაც ხდება ამ კვანძის გახსნის შემდეგ, და არა იმას, გჭირდებათ თუ არა ის.

დაამტკიცეთ, რომელი გზა ააგეთ

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

ss -tnp | grep openvpn

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

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