VPN მუშაობს, მაგრამ ერთ აპს ინტერნეტი არ აქვს? შეამოწმეთ მისი პროქსი

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

რომელი შრე ფლობს პროქსის პარამეტრს

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

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

წაიკითხეთ მნიშვნელობა, რომელსაც თითოეული ხელსაწყო რეალურად იყენებს

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

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

გაუშვით მხოლოდ ის ხაზი, რომელიც თქვენს წინ არსებულ პლატფორმას შეესაბამება, შემდეგ წაიკითხეთ გამოსავალი ჰოსტის, პორტისა და სერტიფიკატებისთვის. მნიშვნელობა, როგორიცაა http://proxy.corp.example:8080 ნიშნავს, რომ ხელსაწყო ყოველი მოთხოვნისთვის ამ ჰოსტს ეკითხება, ხოლო ცარიელი შედეგი ნიშნავს, რომ ის პირდაპირ მიდის და ნამდვილი ხარვეზი სხვაგანაა. დაფარეთ მომხმარებლისა და პაროლის ნაწილი, სანამ გამოსავალს ბილეთში ჩასვამთ, რადგან ეს სტრიქონები გაცილებით ხშირად ცოცხალი სერტიფიკატებია, ვიდრე ადამიანები ფიქრობენ.

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

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

შეცვალეთ ერთი შრე, შემდეგ ზუსტად გაიმეორეთ ის მოთხოვნა, რომელიც ვერ შესრულდა, რადგან სხვა URL არაფერს ამტკიცებს. ჯერ გაასუფთავეთ გარემოს ცვლადები მიმდინარე shell-ში, რადგან ეს ცვლილება შექცევადია და გვირაბს ვერ დააზიანებს:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

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

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

შეამოწმეთ, რომ გასწორება გადატვირთვას გადაურჩება

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

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

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

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