Pse një proxy PAC në një VM mike dështon me URL-në e hostit

„Host-i përdor këtë skedar PAC, prandaj vendosa të njëjtin URL në VM“ është një fjali e arsyeshme dhe një plan i paplotë. Një URL PAC tregon një skript politike, jo një proxy. Derisa miku të mund ta marrë atë skript, ta vlerësojë me adresat e vetë mikut dhe më pas të arrijë çdo proxy që skripti emërton, URL-ja është thjesht një varg në një fushë cilësimesh. Shumica e konfuzionit rreth politikës së proxy-t në makinat virtuale vjen nga trajtimi i asaj rreshte të vetme si e gjithë konfigurimi.

Një URL PAC është skript, jo proxy

Skedari përmban një funksion që merr një URL dhe një host dhe kthen një përshkrim proxy ose fjalën DIRECT. Asgjë në URL nuk i thotë aplikacionit ku ta dërgojë trafikun; ky vendim merret në kohën e ekzekutimit, brenda skriptit, me të dhëna që skripti i kërkon platformës. Një dritare cilësimesh që pranon një URL PAC po pranon një tregues drejt një procedure vendimi.

Ky dallim është arsyeja pse kopjimi i URL-së mund të duket sikur funksionoi. Fusha mbushet, cilësimi ruhet, dhe dështimi shfaqet vetëm më vonë, kur skripti nuk mund të merret ose kur kthen një proxy që miku nuk mund ta arrijë.

Katër hapat dështojnë secili në mënyrën e vet

Brenda mikut katër gjëra duhet të ndodhin me radhë, dhe secila ka nënshkrimin e vet të gabimit. Miku merr skedarin PAC. Aplikacioni vlerëson skriptin për URL-në e kërkuar duke përdorur informacion lokal. Proxy-t e zgjedhur zgjidhen dhe arrihen. Vërtetimi ndodh nëse proxy kërkon atë.

Filloni duke vërtetuar marrjen, sepse pa të gjithçka tjetër është e pakuptimtë. Një skedar PAC në një server privat kërkon një rrugë të lejuar drejt atij serveri përpara se ndonjë rregull të mund të ndihmojë, dhe një zgjedhje proxy brenda një skripti të paarritshëm nuk mund të krijojë rrugën që do ta merrte:

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

Nëse ajo kërkesë dështon nga miku dhe funksionon nga host-i, problemi është rruga e mikut drejt serverit PAC, jo përmbajtja e skriptit. Nëse kthen një skedar JavaScript, kaloni në hapin e dytë dhe zbuloni çfarë vendos skripti për kontekstin e mikut.

I njëjti skript vendos ndryshe brenda një VM

Funksionet PAC mund të inspektojnë host-in e kërkuar dhe informacion rreth makinës që kryen vlerësimin. Një rregull i ndërtuar mbi adresën e vetë klientit, për shembull ai që kontrollon një adresë ndërfaqeje ose anëtarësim në një nënrrjet, do të shohë adresën e mikut dhe jo atë të host-it fizik. Pas NAT-it në anën e host-it këto janë adresa të ndryshme, prandaj i njëjti skript mund të zgjedhë një proxy tjetër ose të kthehet në DIRECT brenda VM-së.

Ky nuk është defekt në skript. Skripti po bën saktësisht atë për të cilën u shkrua, me një hyrje tjetër, dhe kjo shpjegon raportin konfuz ku host-i përdor proxy-n dhe miku lidhet drejtpërdrejt. Rihapni vendimin në vend që të arsyetoni për të: një vlerësues PAC që merr adresë dhe URL, nëse shpërndarja juaj ka një të tillë, e zgjidh çështjen me një komandë. Përndryshe testoni me aplikacionin që do të përdoret vërtet, dhe lexoni regjistrin e proxy-t të tij në vend që të hamendësoni.

Mos arrini në përfundimin se miku trashëgoi cilësimet e proxy-t të host-it sepse trafiku i tij kalon nëpër një përkthim në anën e host-it. Përkthimi i rrjetit përcjell paketa; ai nuk kopjon konfigurimin e aplikacioneve, dhe proxy e sistemit është konfigurim aplikacioni.

Mjete që nuk lexojnë fare PAC

Mjetet e rreshtit të komandës janë një kufi më vete, dhe pikërisht aty humbet shumë kohë. curl nuk ekzekuton skedarë PAC, siç thotë qartë dokumentacioni i tij për proxy-n . Drejtimi i një ndryshoreje proxy drejt URL-së së shkarkimit të PAC nuk e kthen skriptin në një pikë fundore proxy; mjeti do të përpiqet të flasë HTTP me një skedar JavaScript dhe do të dështojë në një mënyrë që duket si problem rrjeti.

E njëjta gjë vlen për shumë menaxherë paketash, mjedise ekzekutimi gjuhësh dhe mjete ndërtimi, që respektojnë vetëm ndryshore proxy të shprehura ose konfigurimin e tyre. Nëse testi që ju intereson është një mjet CLI, konfiguroni atë me proxy-n konkret që skripti PAC do të kishte zgjedhur, dhe shënoni si arritët në atë zgjedhje, që personi tjetër ta përsërisë.

Për aplikacionet e desktopit në Linux, cilësimi i sistemit duhet të vendoset në modalitet automatik dhe gjithashtu t'i jepet një URL; një URL e ruajtur ndërsa modaliteti është ende manual nuk bën asgjë. Kontrolloni të dyja, dhe kontrolloni ato brenda mikut:

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

DIRECT është gjithashtu një vendim

Një rezultat PAC prej DIRECT do të thotë që aplikacioni anashkalon proxy-n HTTP, jo se ka shpëtuar nga rrjeti. Lidhja që rezulton mund të ndjekë ende një rrugë të sistemit operativ përmes një tuneli, ose të dështojë për arsye që nuk kanë asnjë lidhje me përdorimin e proxy-t. Anasjelltas, një rezultat proxy përshkruan kërkesën e një aplikacioni, jo çdo proces në mik.

Prandaj verifikoni në drejtimin në të cilin është shkruar kërkesa. Nëse kërkesa është «ky aplikacion arrin faqen e brendshme», provoni që ai aplikacion e arrin, dhe shënoni cili proxy ose rrugë e transportoi. Nëse kërkesa është «VM-ja është në rrjetin e korporatës», një shfletues që punon përmes një proxy të zgjedhur është provë për atë shfletues dhe asgjë më shumë.

Rregulloni zinxhirin brenda mikut në vend që të fikni tunelin e host-it ose të lehtësoni politikën e përcjelljes që një test të kalojë. Zinxhiri ka katër hallka, dhe një ndryshim që kapërcen njërën prej tyre do të zgjasë deri herën tjetër kur skripti përditësohet ose adresa e mikut ndryshon.