Mac-ის VPN და PAC პროქსი: ორი გადაწყვეტილება, არა ერთი პარამეტრი

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

სად იშლება PAC მისამართი და პროქსი

https://config.corp.example/proxy.pac-ის მსგავსი მისამართი ასახელებს ჩამოსატვირთ დოკუმენტს, და ეს დოკუმენტი ასახელებს სერვერს, რომლითაც ტრაფიკი უნდა გაიაროს. URL-ის პროქსის ჰოსტის ველში ჩასმა სთხოვს კლიენტს გახსნას პროქსი კავშირი ფაილურ სერვერთან, რომელიც ასეთ კავშირს არასოდეს უსმენს. ფაილის შიგნით არის ფუნქცია, რომელსაც კლიენტი ყოველ მოთხოვნაზე იძახებს, და მისი დაბრუნების მნიშვნელობა არის შემდეგი ნაბიჯი იმ ერთი დანიშნულებისთვის. ეს არაპირდაპირობა ხსნის, თუ რატომ შეიძლება ერთსა და იმავე ქსელურ სერვისზე ორი მანქანა განსხვავებულად მოიქცეს, მაშინ როცა ორივეს სწორი URL აქვს. ის ასევე ხსნის, თუ რატომ ძალაში შედის პოლიტიკის ცვლილება იმის გარეშე, რომ ვინმემ თავად პროქსის შეეხოს.

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

სკრიპტი უნდა იქნას მოტანილი, სანამ ის რაიმეს გადაწყვეტს

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

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

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

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

რას გამოტოვებს სინამდვილეში DIRECT პასუხი

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

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

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

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

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

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

რა გადასცეთ ბილეთთან ერთად

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

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