Waarom ’n PAC-proxy in ’n gas-VM met die gasheer se URL misluk

“Die gasheer gebruik hierdie PAC-lêer, so ek het dieselfde URL in die VM gesit” is ’n redelike sin en ’n onvolledige plan. ’n PAC-URL wys na ’n beleidsskrip, nie na ’n proxy nie. Totdat die gas daardie skrip kan gaan haal, dit met die gas se eie adresse geëvalueer het en dan die proxy kan bereik wat die skrip noem, is die URL net ’n string in ’n instellingsveld. Die meeste verwarring oor proxybeleid in virtuele masjiene kom daaruit dat daardie een reël as die hele konfigurasie beskou word.

’n PAC-URL is ’n skrip, nie ’n proxy nie

Die lêer bevat ’n funksie wat ’n URL en ’n gasheer neem en ’n proxybeskrywing of die woord DIRECT teruggee. Niks in die URL sê vir die toepassing waarheen die verkeer moet gaan nie; daardie besluit vind tydens looptyd plaas, binne die skrip, met data wat die skrip by die platform aanvra. ’n Instellingsvenster wat ’n PAC-URL aanvaar, aanvaar ’n wyser na ’n beslissingsprosedure.

Daardie onderskeid is die rede waarom die kopiëring van die URL kan lyk of dit gewerk het. Die veld is gevul, die instelling is gestoor, en die fout verskyn eers later, wanneer die skrip nie gaan haal kan word nie of wanneer dit ’n proxy teruggee wat die gas nie kan bereik nie.

Die vier stappe misluk elkeen anders

Binne die gas moet vier dinge in volgorde gebeur, en elkeen het sy eie foutpatroon. Die gas haal die PAC-lêer. Die toepassing evalueer die skrip vir die versoekte URL met plaaslike inligting. Die gekose proxy word opgelos en bereik. Verifikasie vind plaas as die proxy dit vereis.

Begin deur die ophaal te bewys, want alles stroomaf is betekenisloos daarsonder. ’n PAC-lêer op ’n private bediener vereis ’n toegelate pad na daardie bediener voordat enige reël kan help, en ’n proxykeuse binne ’n onbereikbare skrip kan nie die pad skep wat dit sou gaan haal nie:

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

As daardie versoek van die gas af misluk en van die gasheer af werk, is die probleem die gas se pad na die PAC-bediener, nie die skrip se inhoud nie. As dit ’n JavaScript-lêer teruggee, gaan na die tweede stap en vind uit wat die skrip vir die gas se konteks besluit.

Dieselfde skrip besluit anders binne ’n VM

PAC-funksies kan die versoekte gasheer en inligting oor die masjien wat die evaluering doen, inspekteer. ’n Reël wat op die kliënt se eie adres gebou is, byvoorbeeld een wat ’n koppelvlakadres of ’n subnettoets nagaan, sal die gas se adres sien eerder as dié van die fisiese gasheer. Agter gasheerkant-NAT is dit verskillende adresse, en dieselfde skrip kan dus ’n ander proxy kies of binne die VM na DIRECT terugval.

Dit is nie ’n fout in die skrip nie. Dit is die skrip wat presies doen waarvoor dit geskryf is, met ’n ander inset, en dit verduidelik die verwarrende verslag waar die gasheer die proxy gebruik en die gas direk koppel. Herhaal die besluit eerder as om daaroor te redeneer: ’n PAC-evalueerder wat ’n adres en ’n URL neem, as jou verspreiding een het, beslis die vraag in een opdrag. Anders toets met die toepassing wat werklik gebruik gaan word, en lees sy proxylog in plaas daarvan om te raai.

Moenie aflei dat die gas die gasheer se proxyinstellings geërf het omdat sy verkeer deur gasheerkant-vertaling gaan. Netwerkvertaling stuur pakkette aan; dit kopieer nie toepassingskonfigurasie nie, en die stelselproxy is toepassingskonfigurasie.

Gereedskap wat PAC glad nie lees nie

Opdragreël-gereedskap is ’n aparte grens, en dit is waar baie tyd verlore gaan. curl voer nie PAC-lêers uit nie, soos sy proxy-dokumentasie duidelik sê. Om ’n proxyveranderlike na die PAC-aflaai-URL te wys, maak nie die skrip ’n proxy-eindpunt nie; die gereedskap sal probeer om HTTP met ’n JavaScript-lêer te praat en misluk op ’n manier wat soos ’n netwerkprobleem lyk.

Dieselfde geld vir baie pakketbestuurders, taalplatforms en bougereedskap, wat eksplisiete proxyveranderlikes of hul eie konfigurasie eerbiedig en niks anders nie. As die toets waaroor jy gaan om ’n CLI-gereedskap is, konfigureer dit met die konkrete proxy wat die PAC-skrip sou gekies het, en teken aan hoe jy daardie keuse afgelei het sodat die volgende persoon dit kan herhaal.

Vir lessenaartoepassings op Linux moet die stelselinstelling op outomatiese modus gesit word en ook ’n URL kry; ’n URL wat gestoor word terwyl die modus nog handmatig is, doen niks. Kontroleer albei, en kontroleer dit binne die gas:

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

DIRECT is ook ’n besluit

’n PAC-resultaat van DIRECT beteken die toepassing omseil die HTTP-proxy, nie dat dit die netwerk vrygespring het nie. Die gevolglike verbinding kan steeds ’n bedryfstelselroete deur ’n tonnel volg, of misluk om redes wat niks met proxygebruik te doen het nie. Omgekeerd beskryf ’n proxyresultaat een toepassing se versoek, nie elke proses in die gas nie.

Verifieer dus in die rigting waarin die vereiste geskryf is. As die vereiste is “hierdie toepassing bereik die interne werf”, bewys dat daardie toepassing dit doen, en noteer watter proxy of roete dit gedra het. As die vereiste is “die VM is op die korporatiewe netwerk”, is ’n werkende blaaier deur ’n gekose proxy bewyse vir daardie blaaier en niks meer nie.

Maak die ketting binne die gas reg eerder as om die gasheer se tonnel af te skakel of deurstuurbeleid te verslap om ’n toets te laat slaag. Die ketting het vier skakels, en ’n verandering wat een daarvan oorslaan, hou tot die volgende keer dat die skrip opgedateer word of die gas se adres verander.