რას აკეთებს სინამდვილეში Proxy ველი Apple VPN პროფილში
პროქსის ველის შევსება VPN-ს HTTP-დ არ აქცევს. ჩართულია ორი კავშირი და ველი მხოლოდ ერთ მათგანს აღწევს.
Apple VPN კონფიგურაციაში Proxy ველის შევსება ისე ჩანს, თითქოს გვირაბი ვებ პორტზე უნდა გადამისამართოს. არ აკეთებს. ველი ირჩევს აპლიკაციის დონის შუამავალს იმ ტრაფიკისთვის, რომლის იქ გაგზავნასაც თავსებადი აპი გადაწყვეტს. ხოლო VPN კლიენტის საკუთარი კავშირი მის კარიბჭესთან განისაზღვრება თქვენ მიერ კონფიგურირებული პროტოკოლით, მსმენელითა და ტრანსპორტით, და ეს ცალკეული გადაწყვეტილებებია.
ორი კავშირი, ორი მფლობელი
ასეთი ნებისმიერი კონფიგურაცია მოიცავს კავშირს კლიენტიდან კარიბჭესთან და კავშირს აპიდან დანიშნულებამდე. Proxy განყოფილება მეორეზე საუბრობს, თუმცა ის პირველის იმავე პროფილშია.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Apple-ის პროქსის პარამეტრების ცნობარი ჩამოთვლის HTTP, HTTPS, SOCKS და ავტომატურ პროქსის კონფიგურაციას, რაც აპების პროქსის არჩევანს აღწერს. ამ ჩანაწერებიდან არც ერთი არ ამბობს, როგორ აღწევს IPsec ან WireGuard პაკეტი კარიბჭეს.
აი სწრაფი შემოწმება, რომელიც საკითხს წყვეტს. დაასახელეთ პორტი და პროტოკოლი, რომლებსაც VPN კლიენტი თავის ჟურნალში აცნობს. თუ ეს ხაზი კვლავ ამბობს UDP 500 ან UDP 51820, პროქსის ველს მასში არაფერი შეუცვლია.
როდის არის ველი სწორი იარაღი
არსებობს რეალური შემთხვევა, როცა პროქსი გვირაბის წინ დგას, მაგრამ ეს კლიენტის თვისებაა და არა პროფილის ველი. OpenVPN-ის სახელმძღვანელო აღწერს --http-proxy-ს HTTP CONNECT პროქსით გადატანილი TCP კავშირებისთვის. მისი გამოყენება მოითხოვს შესაბამის კლიენტის ოფციას, ამ გზით მისაწვდომ კარიბჭეს და პროქსის, რომელიც ნებას რთავს CONNECT-ს გამოყენებულ პორტზე.
თუ თქვენი კლიენტი გთავაზობთ ამ ოფციას და ქსელი ნებას რთავს CONNECT-ს პორტზე, შეიძლება იმუშაოს. თუ კლიენტი არ გთავაზობთ, სისტემური პროქსის შევსება გვირაბზე საერთოდ არ მოქმედებს.
როდის არაფერს ცვლის
IKEv2 ან IPsec პროფილი HTTP გვირაბად არ იქცევა იმის გამო, რომ პროქსის ველი შევსებულია. WireGuard-იც არა, რომლის კონფიგურაციის ფორმატს პროქსის ცნება არ აქვს. კარიბჭის პორტის შეცვლა მის პროტოკოლსაც არ ცვლის. და ჩვეულებრივ HTTPS-ზე პასუხისმგებელი ბოლო წერტილი ავტომატურად VPN მსმენელი არ არის.
იგივე ხაფანგი იჭერს მათ, ვინც ძველი iPad გზამკვლევებიდან PPTP ეპოქის პროფილებს აკოპირებს. ოფციები ინტერფეისში ჯერ კიდევ არსებობს; მათ უკან არსებული სერვისი აღარ საუბრობს ამ პროტოკოლზე.
რომელი შრის გასწორება უნდა გადაწყდეს
სანამ რამეს შეცვლით, ჰკითხეთ რომელი შრე ჩავარდა. თუ კლიენტი ვერ ამყარებს სესიას, პრობლემა ტრანსპორტშია და პროქსის ველს მნიშვნელობა არ აქვს. თუ გვირაბი მუშაობს, მაგრამ ერთი აპი ვერ აღწევს თავის სერვერზე, ღირს აპის პროქსის შემოწმება. თუ გვირაბი მუშაობს და ყველა აპი ვარდება, ეჭვმიტანილები გვირაბის შიგნით მარშრუტიზაცია და DNS არიან.
პირველი შემთხვევისთვის ჰკითხეთ ოპერატორს, რომელ დამტკიცებულ ალტერნატიულ ტრანსპორტს ან ქსელს უჭერს მხარს. OpenVPN TCP 443-ზე არსებობს იმიტომ, რომ ზოგიერთი ქსელი მხოლოდ ამას უშვებს, და ის მაინც მოითხოვს, რომ სერვერი მოუსმინოს.
დაბლოკილი UDP პორტი არ მიიღოთ იმპროვიზაციის ნებართვად. შეინარჩუნეთ კარიბჭის სერტიფიკატის ან იდენტურობის შემოწმებები ხელუხლებელი, ნაცვლად იმისა, რომ გამორთოთ ისინი ხელის ჩამორთმევის მორგებისთვის.
დაადასტურეთ ორივე შრე ცალ-ცალკე
ჯერ დაადასტურეთ გვირაბი: კლიენტის სტატუსის გვერდზე შეამოწმეთ დამყარებული სესია და ნულისგან განსხვავებული ბაიტების რაოდენობა. შემდეგ წაიკითხეთ პროქსის პარამეტრი პირდაპირ, ეფექტური კონფიგურაციისთვის scutil --proxy-ით ან შენახული მნიშვნელობისთვის networksetup -getwebproxy Wi-Fi-ით. შემდეგ გამოსცადეთ ერთი აპი, რომელიც პატივს სცემს სისტემურ პროქსის, და ერთი, რომელიც უგულებელყოფს მას, რადგან ბევრი მშობლიური აპი უგულებელყოფს მას.
სამი შედეგი, სამი განსხვავებული შესწორება.
თუ ორივე შრე წარმატებას აცხადებს და აპი კვლავ ვარდება, შეხედეთ გაყოფილ გვირაბიზაციას, DNS-ს და თავად აპის ქსელურ პარამეტრებს. ეს მესამე შრეა და ისიც არ არის პროქსის ველი.