curl ვერ კითხულობს თქვენს PAC ფაილს: სამაგიეროდ გადასცეთ proxy
PAC არის JavaScript პოლიტიკა; curl-ს სჭირდება საბოლოო წერტილი. ჰკითხეთ, რომელ proxy-ს ირჩევს პოლიტიკა თქვენი URL-ისთვის, გადასცეთ ის და დააკვირდით NO_PROXY-სა და TLS-ს.
PAC ფაილის მისამართი და proxy-ს საბოლოო წერტილი კონფიგურაციის ფაილში ურთიერთშემცვლელად გვეჩვენება, მაგრამ ასე არ არის. ერთი პოლიტიკის პროგრამაა, რომელიც თითოეული URL-ისთვის უნდა შეფასდეს; მეორე კი ჰოსტი და პორტია, რომელიც კავშირებს იღებს. curl მხოლოდ მეორეს იგებს. PAC მისამართის გადაცემა --proxy-ზე კატეგორიის შეცდომაა, რომელიც გაუგებარი სახით ვარდება, ჩვეულებრივ ვებ სერვერამდე ხანგრძლივი CONNECT ლოდინის შემდეგ.
რა არის სინამდვილეში თითოეული
| თქვენ გაქვთ | რა არის ეს | რას აკეთებს curl ამით |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript, რომელიც მოცემული URL-ისთვის აბრუნებს proxy-ს ან პირდაპირ კავშირს | იღებს მას როგორც ფაილს და იქ ჩერდება |
http://proxy.corp.example:8080 | მსმენელი, რომელიც იღებს proxy-ით გამავალ მოთხოვნებს | იყენებს მას, მათ შორის CONNECT-ს HTTPS სამიზნეებისთვის |
ამას ცხადად ამბობს curl-ის ხშირად დასმული კითხვები. curl არ იძლევა JavaScript-ის ან PAC-ის ინტერპრეტაციას. curl-ის გარშემო PAC-ის გამგებელი გარსი შეიძლება, მაგრამ თავად curl არა, და არც ერთი დროშა არ აქცევს მას ბრაუზერად.
რატომ მუშაობს ბრაუზერი და curl არა
ბრაუზერი სისტემის proxy კონფიგურაციას ერწყმის, იღებს PAC ფაილს და ამუშავებს მის წესებს თქვენს მიერ გახსნილ URL-ზე. ეს შეფასება PAC ფაილის მიერ მოწოდებული სერვისია და ხდება ბრაუზერის შიგნით, არა თქვენს ტერმინალში.
PAC ფაილის curl-ით ჩამოტვირთვა მხოლოდ მის ტექსტს იღებს. ეს არ აიძულებს curl-ს შეასრულოს პოლიტიკა, და მისი ხელით კითხვა proxy-ს საპოვნელად იგივე შეფასების ხელით ვერსიაა, არასწორი ტოტის არჩევის იმავე შანსით. თუ კითხულობთ, წაიკითხეთ return განაცხადი, რომელიც თქვენს ჰოსტს შეესაბამება და არა ფაილში პირველი proxy-ის სახელი. PAC ფაილების უმეტესობა რამდენიმეს შეიცავს და მხოლოდ ერთი ტოტი გეხებათ.
დამტკიცებული HTTP proxy-სა და დამტკიცებული HTTPS სერვისისთვის საილუსტრაციო მოთხოვნა ასეთია:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusპირველი მისამართი proxy-ს მსმენელია, მეორე კი სერვისი, რომელიც გსურთ. ეს სანიმუშო საბოლოო წერტილებია და არა ვინმეს ჩატარებული ტესტი, ამიტომ ჩაანაცვლეთ ისინი თქვენი ორგანიზაციის სქემით, პორტითა და ავთენტიფიკაციის პროცესით.
აირჩიეთ proxy ამ დანიშნულებისთვის
ჰკითხეთ ადმინისტრატორს, პოლიტიკა თქვენთვის საჭირო URL-ისთვის რომელ proxy-ს ირჩევს და არა იმას, რომელი proxy აქვს ორგანიზაციას. PAC წესები შეიძლება სხვადასხვა შედეგი აბრუნებდეს შიდა სერვისებისთვის, საჯარო საიტებისთვის და მარცხისას გადართვის პირობებისთვის, და წესი, რომელიც დღეს თქვენს URL-ს ემთხვევა, რედაქტირების შემდეგ შეიძლება სხვას დაემთხვეს.
თუ სამუშაო პროცესს ერთზე მეტი ცნობილი მოთხოვნა სჭირდება, გამოიყენეთ ადმინისტრატორის მიერ მხარდაჭერილი სტატიკური პარამეტრი ან დამტკიცებული PAC-ის გამგები ინტეგრაცია. ერთი კოპირებული მისამართის ხისტად ჩაწერა მუშაობს იმ დღემდე, როცა პოლიტიკა შეიცვლება და აღარავის ახსოვს, რატომ შეირჩა ის მისამართი.
შემდეგ შეხედეთ, რას მემკვიდრეობით იღებს curl. proxy-ს გარემოს ცვლადები და NO_PROXY შეიძლება გადაფაროს ან გამორიცხოს თქვენ მიერ გადაცემული proxy, და თქვენს სამიზნესთან შესაბამისი გამორიცხვა მოთხოვნას ჩუმად პირდაპირ აგზავნის. შეინარჩუნეთ განზრახული პოლიტიკა, ნაცვლად იმისა, რომ ყველა გამორიცხვა წაშალოთ ან ყველაფერი ერთი მისამართით აიძულოთ. შეასრულეთ მოთხოვნა ერთხელ -v-ით და შეამოწმეთ, რომელ მისამართს დაუკავშირდა ის რეალურად.
გაყავით TLS-ის ორი იდენტობა
HTTPS proxy-ის შემთხვევაში ორი TLS კავშირი მოქმედებს. თქვენი proxy-სკენ და proxy-ის დანიშნულებისკენ. თითოეულს საკუთარი იდენტობა აქვს შესამოწმებელი, და რომელიმესთვის შემოწმების გამორთვა PAC-ის შესწორება არ არის, არამედ მეორე პრობლემაა, რომელიც პირველს ემატება.
დატოვეთ შემოწმება ჩართული და წაიკითხეთ მიღებული წარუმატებლობა. proxy-ს ავთენტიფიკაციის გამოწვევა, მიუწვდომელი proxy და ვებსაიტის უარი სამი განსხვავებული შედეგია და მხოლოდ პირველი ეხება სერთიფიკატებს. VPN-მა მაინც უნდა უზრუნველყოს დაშვებული გზა კერძო proxy-მდე, მათ შორის proxy ჰოსტის სახელის გარჩევა, სანამ ამათგან რომელიმე წარმატებით დასრულდება.
ჩაწერეთ საბოლოო წერტილი, სქემა, პორტი, ავთენტიფიკაციის მეთოდი, გამორიცხვები და VPN-ის გზა proxy-მდე. სწორედ ეს ჩანაწერი ხდის შემდეგ მოთხოვნას გამეორებადს და ეს არის განსხვავება თქვენი proxy-ს ცოდნასა და მასზე გამოცნობას შორის.