რატომ არ მუშაობს PAC პროქსი სტუმარ VM-ში ჰოსტის URL-ით

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

PAC URL სკრიპტია და არა პროქსი

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

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

ოთხი ნაბიჯი თითოეული თავისებურად ცდება

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

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

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

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

იგივე სკრიპტი VM-ის შიგნით სხვაგვარად წყვეტს

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

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

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

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

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

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

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

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT-იც გადაწყვეტილებაა

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

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

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