Kial PAC-prokuro en VM-gasto malsukcesas ĉe la URL de la gastiganto

„La gastiganto uzas ĉi tiun PAC-dosieron, do mi metis la saman URL-on en la VM-on“ estas prudenta frazo kaj nekompleta plano. PAC-URL montras al politika skripto, ne al prokuro. Ĝis la gasto povas elpreni tiun skripton, taksi ĝin per la propraj adresoj de la gasto kaj poste atingi ajnan prokuron, kiun la skripto nomas, la URL estas nur ĉeno en agorda kampo. La plej granda parto de la konfuzo pri prokura politiko en virtualaj maŝinoj venas de tio, ke oni traktas tiun unu linion kiel la tutan agordon.

PAC-URL estas skripto, ne prokuro

La dosiero enhavas funkcion, kiu prenas URL-on kaj gastiganton kaj redonas prokuran priskribon aŭ la vorton DIRECT. Nenio en la URL diras al la aplikaĵo, kien sendi trafikon; tiu decido okazas dum plenumo, interne de la skripto, per datumoj, kiujn la skripto petas de la platformo. Agorda dialogo, kiu akceptas PAC-URL-on, akceptas montrilon al decida proceduro.

Tiu distingo klarigas, kial kopii la URL-on povas ŝajni sukcesa. La kampo estas plenigita, la agordo estas konservita, kaj la fiasko aperas nur poste, kiam la skripto ne povas esti elprenita aŭ kiam ĝi redonas prokuron, kiun la gasto ne povas atingi.

La kvar paŝoj malsukcesas ĉiu laŭ propra maniero

Interne de la gasto kvar aferoj devas okazi laŭvice, kaj ĉiu havas sian propran eraran subskribon. La gasto elprenas la PAC-dosieron. La aplikaĵo taksas la skripton por la petita URL per lokaj informoj. La elektita prokuro estas solvita kaj atingita. Aŭtentigo okazas, se la prokuro postulas ĝin.

Komencu per pruvo de la elpreno, ĉar ĉio malsupra sen ĝi estas sensignifa. PAC-dosiero sur privata servilo postulas permesitan vojon al tiu servilo antaŭ ol ajna regulo povas helpi, kaj prokura elekto interne de neatingebla skripto ne povas krei la vojon, kiu ĝin elprenus:

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

Se tiu peto malsukcesas el la gasto kaj funkcias el la gastiganto, la problemo estas la vojo de la gasto al la PAC-servilo, ne la enhavo de la skripto. Se ĝi redonas JavaScript-dosieron, iru al la dua paŝo kaj eltrovu, kion la skripto decidas por la kunteksto de la gasto.

La sama skripto decidas alie interne de VM

PAC-funkcioj povas inspekti la petitan gastiganton kaj informojn pri la maŝino, kiu faras la takson. Regulo konstruita sur la propra adreso de la kliento, ekzemple tiu, kiu kontrolas interfacan adreson aŭ membrecon en subreto, vidos la adreson de la gasto anstataŭ tiun de la fizika gastiganto. Malantaŭ NAT ĉe la gastiganta flanko tiuj estas malsamaj adresoj, kaj tial la sama skripto povas elekti alian prokuron aŭ fali al DIRECT interne de la VM.

Tio ne estas cimo en la skripto. Ĝi estas la skripto faranta ĝuste tion, por kio ĝi estis verkita, kun alia enigo, kaj tio klarigas la konfuzan raporton, kie la gastiganto uzas la prokuron kaj la gasto konektiĝas rekte. Reproduktu la decidon anstataŭ pripensi ĝin: PAC-taksilo, kiu prenas adreson kaj URL-on, se via distribuo enhavas unu, solvas la demandon per unu komando. Alie testu per la aplikaĵo, kiu efektive estos uzata, kaj legu ĝian prokuran protokolon anstataŭ diveni.

Ne konkludu, ke la gasto heredis la prokurajn agordojn de la gastiganto ĉar ĝia trafiko pasas tra traduko ĉe la gastiganta flanko. Reta traduko plusendas pakaĵojn; ĝi ne kopias aplikaĵan agordon, kaj la sistema prokuro estas aplikaĵa agordo.

Iloj, kiuj tute ne legas PAC

Komandliniaj iloj estas aparta limo, kaj ĝuste tie perdiĝas multe da tempo. curl ne plenumas PAC-dosierojn, kiel ĝia prokura dokumentaro klare diras. Montrigi prokuran variablon al la PAC-elprena URL ne igas la skripton prokura finpunkto; la ilo provos paroli HTTP kun JavaScript-dosiero kaj fiaskos tiel, ke ĝi aspektas kiel reta problemo.

La samo validas por multaj pakaĵmastrumiloj, lingvaj plenumiloj kaj konstruiloj, kiuj respektas nur eksplicitajn prokurajn variablojn aŭ sian propran agordon. Se la testo, kiu gravas al vi, estas CLI-ilo, agordu ĝin per la konkreta prokuro, kiun la PAC-skripto estus elektinta, kaj notu, kiel vi derivis tiun elekton, por ke la sekva persono povu ripeti ĝin.

Por labortablaj aplikaĵoj en Linux, la sistema agordo devas esti metita en aŭtomatan reĝimon kaj ankaŭ ricevi URL-on; URL konservita dum la reĝimo ankoraŭ estas permana faras nenion. Kontrolu ambaŭ, kaj kontrolu ilin interne de la gasto:

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

DIRECT ankaŭ estas decido

PAC-rezulto DIRECT signifas, ke la aplikaĵo preterpasas la HTTP-prokuron, ne ke ĝi eskapis el la reto. La rezulta konekto ankoraŭ povas sekvi operaciuman itineron tra tunelo, aŭ fiaski pro kialoj, kiuj tute ne rilatas al prokurado. Inverse, prokura rezulto priskribas la peton de unu aplikaĵo, ne ĉiun procezon en la gasto.

Do kontrolu en la direkto, en kiu la postulo estis verkita. Se la postulo estas „ĉi tiu aplikaĵo atingas la internan retejon“, pruvu, ke tiu aplikaĵo atingas, kaj notu, kiu prokuro aŭ itinero portis ĝin. Se la postulo estas „la VM estas en la entreprena reto“, funkcianta retumilo tra elektita prokuro estas pruvo por tiu retumilo kaj nenio pli.

Riparu la ĉenon interne de la gasto anstataŭ malŝalti la tunelon de la gastiganto aŭ malstreĉi la plusendan politikon por ke testo sukcesu. La ĉeno havas kvar ligilojn, kaj ŝanĝo, kiu preterlasas unu el ili, teniĝos ĝis la venonta fojo, kiam la skripto estos ĝisdatigita aŭ la adreso de la gasto ŝanĝiĝos.