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

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

Windows პროქსის ინახავს თითო კავშირისთვის

ინტერნეტის პარამეტრებში ორი ფენაა, რომლებიც დიალოგში ერთნაირად გამოიყურება. ლოკალური ქსელის პარამეტრები ჩვეულებრივ ლოკალურ კავშირზე ვრცელდება, ხოლო აკრეფის ან VPN-ის ჩანაწერი საკუთარ ასლს ინახავს HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections-ის ქვეშ, ორობითი მნიშვნელობის სახით. ნაცნობი გლობალური რეესტრის მნიშვნელობების ჩაწერა ამ ასლს არ განაახლებს.

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

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

მართულ PAC-ს შეუძლია თავად ხელახლა ჩაირთოს

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

შეამოწმეთ და, თუ უფლებამოსილი ხართ, გამორთეთ ეს ორი გადამრთველი იმ სერვისისთვის, რომელიც ტრაფიკს ატარებს:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

გამოიყენეთ სერვისის ნამდვილი სახელი და არა ვარაუდი. ლეპტოპს, რომელსაც აქვს როგორც უსადენო ქსელი, ისე USB Ethernet ადაპტერი, ორი ასეთი აქვს და თქვენს ტრაფიკს მხოლოდ ერთი ატარებს. scutil --proxy ბეჭდავს მიმდინარე მთავარი სერვისის მნიშვნელობებს. შეადარეთ ეს გამოტანილი მონაცემი იმას, რაც თქვენ შეცვალეთ, სანამ დაასკვნით, რომ პროფილმა გაიმარჯვა.

მიმართეთ ხელსაწყო ნამდვილი ზედა დინებისკენ

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

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

შეტენეთ პროქსი გვირაბში

OpenVPN-ზე დაფუძნებულ კლიენტს შეუძლია მიიღოს პროქსის პარამეტრები, რომლებიც ძალაში შედის გვირაბის აწევის შემდეგ, რაც მოსახერხებელია, როცა მარშრუტები კლიენტის ხელშია:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

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

ზოგი კლიენტი სისტემურ პროქსის საერთოდ არ კითხულობს

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

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

წაიკითხეთ კონფიგურაცია და არა გადამრთველი

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

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