Mac-VPN kaj PAC-prokurilo: du decidoj, ne unu agordo

Via Mac elŝutas politikan skripton kaj poste demandas tiun skripton, kiun peranton peto uzu, dum la tunelo nur decidas, kiel oni atingas la elektitan salteton. Ambaŭ respondoj finiĝas sur la sama ingo, do peto, kiu malsukcesas post kiam ambaŭ sukcesis, aspektas kiel unu fuŝo, kvankam ĝi estas du. Apartigi la elŝuton de la elekto, kaj la elekton de la itinero, estas la plej granda parto de la laboro en ĉi tiuj biletoj. La suba ordo sekvas tion, kion macOS efektive faras, kun la kontroloj, kiuj igas ĉiun etapon videbla.

Kie la PAC-adreso kaj la prokurilo disiĝas

Adreso kiel https://config.corp.example/proxy.pac nomas dokumenton por elŝuti, kaj tiu dokumento nomas servilon por sendi trafikon tra ĝi. Enmeti la URL-on en prokurilan gastigan kampon petas la klienton malfermi prokurilan konekton al dosier-servilo, kiu neniam aŭskultas tian. Ene de la dosiero estas funkcio, kiun la kliento vokas por ĉiu peto, kaj ĝia redona valoro estas la sekva salteto por tiu unu celloko. Tiu nerektaĵo klarigas, kial du maŝinoj ĉe la sama reta servo povas konduti malsame, kvankam ambaŭ havas la ĝustan URL-on. Ĝi ankaŭ klarigas, kial politika ŝanĝo ekvalidas sen ke iu tuŝas la prokurilon mem.

Legu la skripton antaŭ ol interpreti ion ajn malsupre, ĉar la reguloj ene portas la esceptojn de la organizo kaj la ordon, laŭ kiu ili validas. Frua larĝa gamo povas ombrumi postan internan sufikson, kaj gastigo, kiu evidente devus preterpasi la prokurilon, daŭre uzas ĝin. Kiam iu insistas, ke la politiko malĝustas, la skripto estas la sola loko, kie tiu aserto solviĝas.

La skripto devas esti alportita antaŭ ol ĝi decidas ion ajn

Elŝuti la politikon postulas solvitan nomon kaj itineron al tio, kio servas la dosieron, kaj konektita tunelo garantias nek unu nek la alian. Se la gastigo solviĝas nur per privata DNS, la solvilo uzata tiun momenton decidas, ĉu la elŝuto povas komenciĝi. Se la gastigo sidas en privata gamo, la itinero devas ekzisti de ĉi tiu maŝino, ne de la tekkomputilo de kolego. Kopio kaŝmemorigita dum pli frua sesio kaŝas ĉion ĉi, ĝis la kaŝmemoro eksvalidiĝas aŭ la maŝino restartas.

Rulu la tri kontrolojn sube en ordo kaj haltu ĉe la unua malsukceso, ĉar la etapoj ne kunhavas kaŭzon. Kune ili montras, ĉu la politiko estas agordita, ĉu ĝi estas atingebla, kaj kion ĝi redonas.

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

La unua komando presas la prokurilan vortaron por la aktiva servo, inkluzive de ajna aŭtomata agorda URL, kiun la sistemo tenas. La dua raportas la URL-on ligitan al unu nomita servo, kio gravas ĉe tekkomputilo, kiu moviĝas inter Wi-Fi kaj Ethernet. La tria alportas la dosieron sen bildigi ĝin, do 404, tempolimo kaj solvila fiasko restas distingeblaj. Se tiu lasta komando redonas la skripton dum aplikoj ankoraŭ fiaskas, la problemo jam pasis la alporton.

Kion respondo DIRECT efektive preterlasas

La PAC-specifiko donas al la kliento malgrandan vortaron, kaj DIRECT estas unu vorto el ĝi. La vorto diras al la kliento preterpasi la prokurilon por tiu peto kaj diras nenion pri tio, kiun interfacon la ingo poste uzos. Rekta ingo sur plena tunelo tamen eliras tra la VPN kaj tamen montras la eliran adreson de la tunelo al la celloko.

Legi DIRECT kiel ekster la VPN estas la eraro, kiu sendas homojn al la malĝusta agorda panelo. La spegula bildo estas same ofta, ĉar privata prokurilo atingeblas per dividita itinero dum la resto de la maŝino restas ekster la tunelo. Kion la celloko tiam raportas, apartenas al la propra eliro de la prokurilo, kiu povas sidi en alia lando. Skribi la atendon por unu interna gastigo kaj unu publika gastigo rapide malkaŝas tion, ĉar la skripto ofte respondas la du malsame. Post kiam vi scias, kiu salteto produktis la adreson, la raporto ĉesas esti mistera.

Tri fiaskoj, kiuj aperas kiel unu erarpaĝo

La politiko povas malsukcesi elŝutiĝi, la elektita prokurilo povas esti neatingebla, kaj peto, kiu alvenas al la servo, povas esti rifuzita tie. Ĉiuj tri alvenas kiel tempolimo aŭ ĝenerala erarpaĝo, kaj neniu nomas la etapon, kiu rompiĝis. Kapti la decidon apud la eraro estas tio, kio apartigas ilin. La du sondoj sube testas la salteton, kiun la skripto elektis, po unu por ĉiu branĉo, kiun ĝi povas redoni.

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

Kompletigita konekto al la prokurilo movas la demandon al aŭtentikigo aŭ al la propra politiko de la prokurilo, kiu havas alian posedanton. Kompletigita konekto al la interna gastigo sen prokurilo en la vojo ekskludas la itineron kaj montras al la politiko. Ambaŭ komandoj ignoras la prokurilan vortaron de macOS krom se la ŝelo eksportas prokurilajn variablojn, do unue malplenigu ilin. Neniu el la du sondoj pruvas la alian, kaj tial unu erarpaĝo misgvidas tiom longe.

Kion transdoni kun la bileto

Sendu la aktivan retan servon, la PAC-URL-on, la taksorezulton por la malsukcesanta gastigo, kaj la etapon, kie la eraro aperis. Tiuj kvar lasas al la sekva persono reprodukti la decidon anstataŭ diveni, kiu tavolo estis implikita. Aldonu la staton de la tunelo en la momento de la testo, ĉar rezulto kaptita antaŭ rekonekto estas malaktuala. Konservu ankaŭ la revizion de la skripto, ĉar la politika dosiero ŝanĝiĝas sen avizo kaj la hieraŭa respondo eble jam ne validas.

Registru, kiel la kliento kondutas, kiam la skripto ne povas esti alportita, ĉar efektivigoj diferencas kaj la prokurila decido ne estas tut-aparata haltŝaltilo. Iuj falas reen al rekta konekto kaj aliaj fiaskas fermite, kaj tiu diferenco ŝanĝas, ĉu fuŝo aspektas kiel rompita prokurilo aŭ kiel funkcianta politiko. Konfirmu la konduton por la ĝusta kliento kaj versio antaŭ ol fidi ĝin dum okazaĵo.