Mac-i juaj shkarkon një skript politike dhe më pas e pyet atë skript se cili ndërmjetës duhet të përdoret nga një kërkesë, ndërsa tuneli vendos vetëm si arrihet kërcimi i zgjedhur. Të dyja përgjigjet përfundojnë në të njëjtin socket, kështu që një kërkesë që dështon pasi të dyja kanë sukses duket si një defekt i vetëm kur janë dy. Ndarja e shkarkimit nga zgjedhja, dhe e zgjedhjes nga rruga, është pjesa më e madhe e punës në këto bileta. Radha më poshtë ndjek atë që macOS bën në të vërtetë, me kontrollet që e bëjnë çdo fazë të dukshme.

Ku ndryshojnë adresa PAC dhe proxy-i

Një adresë si https://config.corp.example/proxy.pac emërton një dokument për t'u shkarkuar, dhe ai dokument emërton një server përmes të cilit kalon trafiku. Ngjitja e URL-së në një fushë hosti proxy i kërkon klientit të hapë një lidhje proxy me një server skedarësh që nuk dëgjon kurrë një të tillë. Brenda skedarit është një funksion që klienti e thërret për çdo kërkesë, dhe vlera e kthimit është kërcimi tjetër për atë destinacion të vetëm. Ky tërheqësim shpjegon pse dy makina në të njëjtin shërbim rrjeti mund të sillen ndryshe edhe pse të dyja kanë URL-në e saktë. Ai shpjegon gjithashtu pse një ndryshim politike hyn në fuqi pa i prekur askush vetë proxy-n.

Lexoni skriptin përpara se të interpretoni çdo gjë në rrjedhën e poshtme, sepse rregullat brenda tij mbajnë përjashtimet e organizatës dhe radhën në të cilën zbatohen. Një interval i gjerë i hershëm mund të mbulojë një prapashtesë të brendshme të mëvonshme, dhe një host që dukshëm duhet ta anashkalojë proxy-n vazhdon ta përdorë atë. Kur dikush këmbëngul se politika është e gabuar, skripti është vendi i vetëm ku ai pretendim zgjidhet.

Skripti duhet të merret përpara se të vendosë çdo gjë

Shkarkimi i politikës kërkon një emër të zgjidhur dhe një rrugë drejt asaj që shërben skedarin, dhe një tunel i lidhur nuk nënkupton asnjërën. Nëse hosti zgjidhet vetëm përmes DNS privat, resolueri në përdorim në atë moment vendos nëse shkarkimi mund të fillojë. Nëse hosti ndodhet në një interval privat, rruga duhet të ekzistojë nga kjo makinë dhe jo nga laptopi i një kolegu. Një kopje e ruajtur në cache nga një sesion i mëparshëm i fsheh të gjitha këto derisa cache të skadojë ose makina të riniset.

Kryeni tre kontrollet më poshtë me radhë dhe ndaloni në dështimin e parë, sepse fazat nuk ndajnë të njëjtin shkak. Së bashku ato tregojnë nëse politika është konfiguruar, nëse është e arritshme dhe çfarë kthen.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

Komanda e parë printon fjalorin e proxy-t për shërbimin aktiv, duke përfshirë çdo URL të konfigurimit automatik që mban sistemi. E dyta raporton URL-në e lidhur me një shërbim të emërtuar, gjë që ka rëndësi në një laptop që lëviz midis Wi-Fi dhe Ethernet. E treta e merr skedarin pa e renderuar, kështu që një 404, një skadim kohe dhe një dështim resolueri mbeten të dallueshëm. Nëse ajo komandë e fundit kthen skriptin ndërsa aplikacionet ende dështojnë, problemi e ka kaluar tashmë marrjen.

Çfarë kalon në të vërtetë një përgjigje DIRECT

Specifikimi PAC i jep klientit një fjalor të vogël, dhe DIRECT është një nga fjalët e tij. Fjala i thotë klientit të kalojë proxy-n për atë kërkesë dhe nuk thotë asgjë për atë se çfarë ndërfaqe do të përdorë më pas socket-i. Një socket i drejtpërdrejtë në një tunel të plotë del gjithsesi përmes VPN-së dhe gjithsesi i tregon destinacionit adresën e daljes së tunelit.

Leximi i DIRECT si jashtë VPN-së është gabimi që i dërgon njerëzit në panelin e gabuar të cilësimeve. Imazhi në pasqyrë është po aq i zakonshëm, sepse një proxy privat mund të arrihet përmes një rruge të ndarë ndërsa pjesa tjetër e makinës mbetet jashtë tunelit. Ajo që destinacioni raporton atëherë i përket daljes së vetë proxy-t, e cila mund të ndodhet në një vend tjetër. Shkrimi i pritshmërisë për një host të brendshëm dhe një host publik e nxjerr shpejt në pah, sepse skripti shpesh u përgjigjet të dyve ndryshe. Sapo ta dini se cili kërcim e prodhoi adresën, raporti nuk është më misterioz.

Tre dështime që shfaqen si një faqe e vetme gabimi

Politika mund të dështojë në shkarkim, proxy-i i zgjedhur mund të jetë i paarritshëm, dhe një kërkesë që arrin në shërbim mund të refuzohet atje gjithsesi. Të treja vijnë si skadim kohe ose faqe gabimi e përgjithshme, dhe asnjëra nuk emërton fazën që u thye. Kapja e vendimit pranë gabimit është ajo që i ndan. Dy sondat më poshtë testojnë kërcimin që zgjodhi skripti, një për çdo degë që mund të kthejë.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Një lidhje e përfunduar me proxy-n e zhvendos pyetjen në autentikim ose në politikën e vetë proxy-t, e cila ka një pronar tjetër. Një lidhje e përfunduar me hostin e brendshëm pa proxy në rrugë e përjashton rrugën dhe tregon politikën. Të dyja komandat injorojnë fjalorin e proxy-t të macOS nëse shell-i nuk eksporton variabla proxy, prandaj pastrojini së pari. Asnjëra sondë nuk vërteton tjetrën, dhe për këtë arsye një faqe gabimi mashtron kaq gjatë.

Çfarë të dorëzohet me biletën

Dërgoni shërbimin aktiv të rrjetit, URL-në e PAC, rezultatin e vlerësimit për hostin që dështon dhe fazën ku u shfaq gabimi. Këto katër i lejojnë personit tjetër të riprodhojë vendimin në vend që të hamendësojë cila shtresë ishte e përfshirë. Shtoni gjendjen e tunelit në momentin e testit, sepse një rezultat i kapur përpara një rilidhjeje është i vjetëruar. Ruani edhe rishikimin e skriptit, pasi skedari i politikës ndryshon pa njoftim dhe përgjigjja e djeshme mund të mos jetë më e vlefshme.

Regjistroni se si sillet klienti kur skripti nuk mund të merret, sepse implementimet ndryshojnë dhe vendimi për proxy-n nuk është një çelës ndalimi për të gjithë pajisjen. Disa bien përsëri në një lidhje të drejtpërdrejtë dhe të tjerë dështojnë të mbyllur, dhe ky ndryshim ndryshon nëse një ndërprerje duket si proxy i prishur apo si politikë që funksionon. Konfirmoni sjelljen për klientin dhe versionin e saktë përpara se të mbështeteni tek ajo gjatë një incidenti.

Artikuj të ngjashëm