რატომ არ არის VPN საიტიდან 403 პროქსის უკმარისობა
403 წყაროდან, უარყოფილი CONNECT და 407 გამოწვევა სხვადასხვა საზღვარს აღნიშნავს. ჯერ შეადარეთ პროქსის გასასვლელი გზა ბრაუზერის VPN მისამართს.
მომხმარებლები VPN-ს გამორთავენ, შიდა საიტზე 403-ს ხვდებიან და აცხადებენ, რომ პროქსი გაფუჭებულია. ამ გვერდს სამი ცალკე რამ შეიძლება წარმოქმნას: წყარომ მოითხოვა უარი, წინა პროქსმა უარი თქვა გვირაბის გახსნაზე, ან პროქსმა საკუთარი სერტიფიკატები მოითხოვა. თითოეული მათგანი სხვადასხვა კითხვის სწორი პასუხია და მათი ერთ ზოგად უკმარისობის გვერდად გასწორება ანადგურებს ერთადერთ მტკიცებულებას, რაც გაქვთ. დაალაგეთ უარი იმ კომპონენტის მიხედვით, რომელმაც ის შექმნა, შემდეგ შეადარეთ ქსელური გზა, რომელსაც თითოეული კომპონენტი რეალურად იყენებს.
დაასახელეთ კომპონენტი, რომელმაც 403 შექმნა
HTTP სტატუსის კოდი ეკუთვნის იმ მხარეს, რომელმაც გამოგზავნა. როცა წყარო აბრუნებს 403-ს, მან მოითხოვა მოთხოვნის ანალიზი და გადაწყვიტა, რომ გამომძახებელს შეიძლება არ ჰქონდეს რესურსი, რაც ავტორიზაციის პასუხია და არა ტრანსპორტის პრობლემა. როცა წინა პროქსი CONNECT-ზე 403-ს პასუხობს, მან საერთოდ უარი თქვა გვირაბის აშენებაზე და ზემოთ არაფერთან კავშირი არ დამყარებულა. როცა 407-ს პასუხობს, მას საკუთარი სერტიფიკატები სურს, რომელთა კავშირი აპლიკაციის შესვლასთან არ არსებობს.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 განსაზღვრავს ამ როლებს, მათ შორის პროქსისთვის დამახასიათებელ გამოწვევას. სანამ სხეულს წაიკითხავთ, წაიკითხეთ პასუხის საკუთარი სტატუსი და ნებისმიერი Proxy-Authenticate სათაური, რადგან მეგობრული HTML შეცდომის გვერდი ჩვეულებრივ მალავს, რომელმა კომპონენტმა დაწერა ის.
რას მალავს CONNECT გვირაბი ბაიტების გადამცემისგან
მას შემდეგ, რაც პროქსი CONNECT-ზე 200-ს აბრუნებს, ის ბაიტებს გადასცემს და ბრაუზერი საკუთარ TLS სესიას ინარჩუნებს წყაროსთან. ამიტომ ბაიტების გადამცემი პროქსი ვერ წაიკითხავს დაშიფრულ 403-ს ამ სესიის შიგნით და ის არასოდეს ხდება უარის ავტორი. უარი გვირაბის გახსნამდე სრულიად სხვა მოვლენაა, რომელიც ერთი შრით ქვემოთ იქმნება.
TLS-ის დამამთავრებელი უკუპროქსი სხვა მდგომარეობაშია: მას ეკუთვნის TLS საზღვარი, აანალიზებს HTTP-ს და კანონიერად შეუძლია პასუხების გადაწერა ან ჩაჭრა. ეს უნარი კონფიგურაციის არჩევანია და არა პროქსირების ზოგადი თვისება, და ის არ ანიჭებს უფლებას აპლიკაციის წვდომის პოლიტიკის გვერდის ავლაზე. პასუხის წაკითხვა უნარია; გადაწყვეტა, თუ რა შეიძლება დაინახოს გამომძახებელმა, კვლავ წყაროს საქმეა.
პრაქტიკული შედეგი ისაა, რომ 403-ის ინტერპრეტაციამდე უნდა იცოდეთ, სამი ფორმიდან რომელს ამუშავებთ. ნაკადოვან პროქსზე HTTP შემოწმების წესების დამატება მას ხილვადობას არ აძლევს, და ბაიტების გადამცემისგან წყაროს უარის ახსნის მოლოდინი არასწორ ჟურნალში გაგზავნით.
შეადარეთ პროქსის გასასვლელი გზა ბრაუზერის გვირაბის მისამართს
VPN-ზე დაკავშირებული ბრაუზერი ავტომატურად არ გადაიტანს ცალკე პროქს სერვერს ამ გვირაბში. წყარო ხედავს პროქსის გასასვლელ მისამართს, და თუ პროქსი კვლავ ლოკალური ნაგულისხმევი მარშრუტით გადის, დაცული საიტი ხედავს მისამართს, რომლის ნდობაზე არასოდეს ყოფილა კონფიგურირებული. ლეპტოპის შიდა VPN მისამართი ამ წყაროსთვის უხილავია. ეს არის ყველაზე გავრცელებული მიზეზი, რატომ მუშა გვირაბი კვლავ 403-ს იძლევა საიტიდან, რომელიც ყველა სხვის მიმართ სწორად იქცევა.
გამოსცადეთ ორივე გზა ცალ-ცალკე, რომ მისამართები არ აირიოს.
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateპირველი მოთხოვნა აჩვენებს, თუ რას პასუხობს წყარო თქვენს საკუთარ მისამართზე, მეორე — რას პასუხობს პროქსის მისამართზე. დამთხვეული 403 წყვილი წყაროს ავტორიზაციის წესებზე მიუთითებს; 200-ს რომ 403 მოჰყვება, პროქსის გზაზე მიუთითებს. ჰკითხეთ წყაროს მფლობელს, რომელი წყარო მისამართები უშვებს სინამდვილეში წესების ნაკრები, იმის ნაცვლად, რომ ივარაუდოთ VPN აუზის ჩართვა.
გამოსცადეთ თითოეული საზღვარი მისი გამიჯვნის მოთხოვნით
გამოყავით პროქსის ფენა იმით, რომ სთხოვოთ მას ის, რაზეც აპლიკაციური მიზეზებით უარს ვერ იტყვის. CONNECT ჰოსტზე, რომელზეც პროქსს წვდომა ნებადართული აქვს, გამოსავლის გადაგდებით, გეტყვით, მუშაობს თუ არა გვირაბში შეშვება საერთოდ.
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
თუ ეს CONNECT-ისთვის 200-ს და შემდეგ TLS ხელის ჩამორთმევას ბეჭდავს, პროქსის შეშვება რიგზეა და შემდგომი 403 წყაროდან მოვიდა. თუ 407-ს ბეჭდავს, მიაწოდეთ პროქსის სერტიფიკატები --proxy-user-ით და გაიმეორეთ, სანამ საიტზე რაიმე დასკვნას გააკეთებთ. თუ CONNECT ხაზზე 403-ს ბეჭდავს, პროქსის საკუთარი ნებადართულების სიაა გასაკვლევი საზღვარი და აპლიკაცია აქ არ მონაწილეობს.
შეინახეთ სერტიფიკატები shell-ის ისტორიისა და ჩასმული ტრანსკრიპტების გარეთ. ბრძანების ხაზში აკრეფილი პროქსის პაროლი სხვა ლოკალური მომხმარებლებისთვის ხილვადია, და სერტიფიკატებით დაჭერილი CONNECT კვალი უარესია, ვიდრე კვალის არარსებობა.
შეინახეთ განაჩენი წაკითხვადი, გვერდის გადაწერის ნაცვლად
მას შემდეგ, რაც გაიგებთ, რომელმა კომპონენტმა თქვა უარი, შეინახეთ ეს პასუხი. უკუპროქსი, რომელიც წყაროს 403-ს 504 დროის ამოწურვად აღნიშნავს ან წარმატების გვერდით ცვლის, მალავს ავტორიზაციის გადაწყვეტას ხელმისაწვდომობის ისტორიის უკან და შემდეგ პასუხისმგებელს არასწორ გუნდთან აგზავნის. მორგებული შეცდომის გვერდები კარგია, როცა ისინი სტატუსს ინარჩუნებენ და კონტექსტს ამატებენ.
ქეშირება იმავე ზრუნვას იმსახურებს. RFC 9111 არეგულირებს, როგორ შეიძლება საერთო ქეშებმა პასუხების ხელახლა გამოყენება, და ერთი გამომძახებლისთვის შექმნილი უარი არ უნდა გადაეცეს სხვას, თითქოს ნებართვა იყოს. თუ უარის პასუხები საერთოდ ინახება, შეინახეთ ისინი პირად და შეზღუდულად, და არასოდეს დაამატოთ საჯარო სიგრილის წესი მხოლოდ ზედა დინების ტრაფიკის შესამცირებლად.
დაასრულეთ წერილობითი განაჩენით, რომელიც ასახელებს კომპონენტს, მის მიერ შექმნილ სტატუსს და წყაროს მისამართს, რომელიც წყარომ დაინახა. ჩაწერეთ ზუსტი მოთხოვნა, მოქმედი პროქსის პარამეტრები და დრო, რათა შემდეგი ანგარიში შეედაროს იმავე მტკიცებულებებს და არ იქნას ხელახლა გამოტანილი მეხსიერებიდან. ეს ჩანაწერი შემდეგ ანგარიშს წამებში პასუხობს და ხელს უშლის იმავე 403-ის კვლავ VPN შეფერხებად დიაგნოსტირებას.