Zergatik huts egiten duen gonbidatu VM bateko PAC proxyak ostalariaren URLarekin

«Ostalariak PAC fitxategi hau erabiltzen du, beraz URL bera jarri dut VMn» esaldi zentzuzkoa eta plan osatugabea da. PAC URL batek politika-script bat seinalatzen du, ez proxy bat. Gonbidatuak script hori jaitsi, gonbidatuaren beraren helbideekin ebaluatu eta scriptak izendatzen duen proxya iritsi arte, URLa ezarpen-eremu bateko kate bat besterik ez da. Makina birtualetako proxy politikaren inguruko nahasmen gehiena lerro hori konfigurazio osoa balitz bezala tratatzetik dator.

PAC URL bat script bat da, ez proxy bat

Fitxategiak URL bat eta ostalari bat hartu eta proxy deskribapen bat edo DIRECT hitza itzultzen duen funtzio bat dauka. URLean ezerk ez dio aplikazioari trafikoa nora bidali esaten; erabaki hori exekuzio-denboran gertatzen da, scriptaren barruan, scriptak plataformari eskatzen dizkion datuekin. PAC URL bat onartzen duen ezarpen-elkarrizketa batek erabaki-prozedura baterako erakusle bat onartzen du.

Bereizketa hori da URLaren kopia egiteak funtzionatu zuelako itxura har dezakeen arrazoia. Eremua beteta dago, ezarpena gordeta dago, eta hutsegitea geroago soilik agertzen da, scripta jaitsi ezin denean edo gonbidatuak iritsi ezin duen proxy bat itzultzen duenean.

Lau urratsek huts egiten dute bakoitzak modu ezberdinean

Gonbidatuaren barruan lau gauza gertatu behar dira ordenan, eta bakoitzak bere errore-sinadura du. Gonbidatuak PAC fitxategia jaisten du. Aplikazioak eskatutako URLarentzat scripta ebaluatzen du tokiko informazioarekin. Aukeratutako proxya ebazten da eta hara iristen da. Autentifikazioa gertatzen da proxyak eskatzen badu.

Hasi jaitsiera frogatzen, hori gabe ondorengo guztia zentzurik gabea baita. Zerbitzari pribatu batean dagoen PAC fitxategiak zerbitzari horretara baimendutako bide bat behar du edozein erregelak lagundu aurretik, eta script iristezin baten barruko proxy aukerak ezin du jaitsiko lukeen bidea sortu:

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

Eskari horrek gonbidatutik huts egiten badu eta ostalaritik funtzionatzen badu, arazoa gonbidatuaren bidea da PAC zerbitzariraino, ez scriptaren edukia. JavaScript fitxategi bat itzultzen badu, joan bigarren urratsera eta jakin ezazu scriptak gonbidatuaren testuinguruarentzat zer erabakitzen duen.

Script berak beste modu batera erabakitzen du VM baten barruan

PAC funtzioek eskatutako ostalaria eta ebaluazioa egiten duen makinari buruzko informazioa azter ditzakete. Bezeroaren beraren helbidean oinarritutako erregela batek, adibidez interfaze-helbide bat edo azpisare bateko kidetza egiaztatzen duenak, gonbidatuaren helbidea ikusiko du, ez ostalari fisikoarena. Ostalariaren aldeko NATaren atzean helbide desberdinak dira, eta beraz script berak beste proxy bat aukera dezake edo DIRECTera itzul daiteke VMaren barruan.

Hori ez da scriptaren akats bat. Scripta idatzi zeneko lana egiten ari da, beste sarrera batekin, eta horrek azaltzen du ostalariak proxya erabiltzen duen eta gonbidatuak zuzenean konektatzen duen txosten nahasia. Erreproduzitu erabakia, hari buruz arrazoitu beharrean: helbide bat eta URL bat hartzen dituen PAC ebaluatzaile batek, zure banaketak bat badakar, komando bakar batekin argitzen du kontua. Bestela, benetan erabiliko den aplikazioarekin probatu, eta haren proxy erregistroa irakurri asmatu beharrean.

Ez ondorioztatu gonbidatuak ostalariaren proxy ezarpenak heredatu dituenik bere trafikoa ostalariaren aldeko itzulpenetik igarotzen delako. Sare-itzulpenak paketeak birbidaltzen ditu; ez du aplikazioen konfigurazioa kopiatzen, eta sistemako proxya aplikazioaren konfigurazioa da.

PAC inola ere irakurtzen ez duten tresnak

Komando-lerroko tresnak muga bereizi bat dira, eta hemen galtzen da denbora asko. curl ez da PAC fitxategiak exekutatzen, bere proxy dokumentazioak argi dioen bezala. Proxy aldagai bat PAC deskargaren URLera zuzentzeak ez du scripta proxy mutur bihurtzen; tresnak HTTP hitz egiten saiatuko da JavaScript fitxategi batekin eta sare-arazo baten itxura duen moduan huts egingo du.

Gauza bera gertatzen da pakete-kudeatzaile, hizkuntza-exekuzio-ingurune eta eraikuntza-tresna askorekin, proxy aldagai esplizituak edo beren konfigurazioa soilik errespetatzen baitituzte. Zuri interesatzen zaizun proba CLI tresna bat bada, PAC scriptak aukeratuko zukeen proxy zehatzarekin konfiguratu, eta idatzi aukera horretara nola iritsi zaren hurrengo pertsonak errepikatu ahal izan dezan.

Linuxeko mahaigaineko aplikazioetarako, sistemaren ezarpena modu automatikora jarri behar da eta URL bat eman behar zaio; modua oraindik eskuzkoa den bitartean gordetzen den URL batek ez du ezer egiten. Egiaztatu biak, eta egiaztatu gonbidatuaren barruan:

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

DIRECT ere erabaki bat da

PAC emaitza DIRECT izateak aplikazioak HTTP proxya saihesten duela esan nahi du, ez saretik ihes egin duenik. Emaitzazko konexioak oraindik sistema eragilearen ibilbide bat jarrai dezake tunel batetik, edo proxy erabilerarekin zerikusirik ez duten arrazoiengatik huts egin. Alderantziz, proxy emaitza batek aplikazio baten eskaria deskribatzen du, ez gonbidatuko prozesu oro.

Beraz, baldintza idatzi zen noranzkoan egiaztatu. Baldintza «aplikazio hau barneko gunera iristen da» bada, frogatu aplikazio hori iristen dela, eta idatzi zein proxik edo ibilbidek eraman zuen. Baldintza «VM sare korporatiboan dago» bada, aukeratutako proxy baten bidez funtzionatzen duen nabigatzailea nabigatzaile horren froga da eta ez gehiago.

Konpondu katea gonbidatuaren barruan, ostalariaren tunela itzali edo birbidaltze-politika leundu beharrean proba bat gaindi dadin. Kateak lau begizta ditu, eta horietako bat saltatzen duen aldaketa bat mantenduko da scripta hurrengoan eguneratu edo gonbidatuaren helbidea aldatzen den arte.