Wêrom’t in PAC-proxy yn in gast-VM mislearret mei de URL fan ’e host

„De host brûkt dit PAC-bestân, dus ik haw deselde URL yn ’e VM set“ is in ridlike sin en in ûnfolslein plan. In PAC-URL wiist nei in beliedsscript, net nei in proxy. Oant de gast dat script ophelje kin, it mei de eigen adressen fan ’e gast evaluearje kin en dan de proxy berikke kin dy’t it script neamt, is de URL mar in tekenrige yn in ynstellingsfjild. It measte fan ’e betizing oer proxybelied yn firtuele masines komt derfan dat dy iene rigel as de hiele konfiguraasje behannele wurdt.

In PAC-URL is in script, net in proxy

It bestân befettet in funksje dy’t in URL en in host nimt en in proxybeskriuwing of it wurd DIRECT weromjout. Neat yn ’e URL fertelt de applikaasje wêr’t it ferkear hinne moat; dy beslissing falt op runtime, binnen it script, mei gegevens dy’t it script by it platfoarm opfreget. In ynstellingsdialooch dy’t in PAC-URL akseptearret, akseptearret in oanwizer nei in beslissingsproseduere.

Dat ûnderskie is de reden wêrom’t it kopiearjen fan ’e URL lykje kin as hat it wurke. It fjild is fol, de ynstelling is bewarre, en de flater bliuwt pas letter oer, as it script net ophelle wurde kin of as it in proxy weromjout dy’t de gast net berikke kin.

De fjouwer stappen mislearje elk op in oare wize

Binnen de gast moatte fjouwer dingen yn folchoarder barre, en elk hat syn eigen flatertekst. De gast hellet it PAC-bestân op. De applikaasje evaluearret it script foar de frege URL mei lokale gegevens. De keazen proxy wurdt oplost en berikt. Autentikaasje bart as de proxy dat freget.

Begjin mei it opheljen te bewizen, want alles dêrnei is sûnder dat sinleas. In PAC-bestân op in partikuliere server freget in tastiene paad nei dy server foardat hokker regel dan ek helpe kin, en in proxykar binnen in net berikber script kin it paad net meitsje dat it ophelje soe:

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

As dat fersyk út ’e gast mislearret en fan ’e host út wurket, is it probleem it paad fan ’e gast nei de PAC-server, net de ynhâld fan it script. As it in JavaScript-bestân weromjout, gean dan nei de twadde stap en sykje út wat it script foar de kontekst fan ’e gast beslist.

Itselde script beslist oars binnen in VM

PAC-funksjes kinne de frege host en gegevens oer de masine dy’t de evaluaasje docht ynspektearje. In regel boud op it eigen adres fan ’e klant, bygelyks ien dy’t in ynterfaceadres of lidmaatskip fan in subnet kontrolearret, sil it adres fan ’e gast sjen ynstee fan dat fan ’e fysike host. Efter NAT oan ’e hostkant binne dat ferskate adressen, en dêrom kin itselde script in oare proxy kieze of binnen de VM weromfalle op DIRECT.

Dat is gjin flater yn it script. It is it script dat krekt docht wêr’t it foar skreaun is, mei oare ynfier, en dat ferklearret it betiizjende rapport wêrby’t de host de proxy brûkt en de gast direkt ferbynt. Reproduzearje de beslissing ynstee fan deroer te redenearjen: in PAC-evaluaasje-ark dat in adres en in URL nimt, as jo distribúsje ien hat, beslist de fraach mei ien opdracht. Oars testje mei de applikaasje dy’t echt brûkt wurde sil, en lês syn proxylog ynstee fan te rieden.

Konkludearje net dat de gast de proxyynstellingen fan ’e host erfd hat om’t syn ferkear troch oersetting oan ’e hostkant giet. Netwurkoersetting stjoert pakketten troch; it kopiearret gjin applikaasjekonfiguraasje, en de systeemproxy is applikaasjekonfiguraasje.

Ark dat PAC hielendal net lêst

Kommandorigel-ark is in aparte grins, en dêr giet in protte tiid ferlern. curl fiert gjin PAC-bestannen út, sa’t syn proxydokumintaasje dúdlik seit. In proxyfariabele op ’e PAC-download-URL rjochtsje makket it script gjin proxy-einpunt; it ark sil besykje HTTP te praten mei in JavaScript-bestân en mislearje op in wize dy’t op in netwurkprobleem liket.

Itselde jildt foar in protte pakketbehearders, taalruntimes en bou-ark, dy’t allinnich eksplisite proxyfariabelen of har eigen konfiguraasje respektearje. As de test dy’t jo oanbelanget in CLI-ark is, konfigurearje it dan mei de konkrete proxy dy’t it PAC-script keazen hawwe soe, en notearje hoe’t jo ta dy kar kamen, sadat de folgjende persoan it werhelje kin.

Foar desktop-applikaasjes op Linux moat de systeemynstelling op automatyske modus set wurde en ek in URL krije; in URL dy’t bewarre wurdt wylst de modus noch hânmjittich is, docht neat. Kontrolearje beide, en kontrolearje se binnen de gast:

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

DIRECT is ek in beslissing

In PAC-resultaat fan DIRECT betsjut dat de applikaasje de HTTP-proxy foarby giet, net dat it oan it netwurk ûntkommen is. De resultearjende ferbining kin noch altyd in bestjoeringssysteemrûte troch in tunnel folgje, of mislearje om redenen dy’t neat mei proxygebrûk te meitsjen hawwe. Oarsom beskriuwt in proxyresultaat it fersyk fan ien applikaasje, net elk proses yn ’e gast.

Ferifiearje dus yn ’e rjochting wêryn’t de eask skreaun is. As de eask is „dizze applikaasje berikt de ynterne side“, bewiisje dat dy applikaasje dat docht, en notearje hokker proxy of rûte it droegen hat. As de eask is „de VM is op it bedriuwsnetwurk“, is in wurkjende browser fia in keazen proxy bewiis foar dy browser en net mear.

Reparearje de keatling binnen de gast ynstee fan ’e tunnel fan ’e host út te setten of it trochstjoerbelied te fersêftsjen om in test te slagjen. De keatling hat fjouwer skeakels, en in feroaring dy’t ien dêrfan oerslacht, hâldt oant de folgjende kear dat it script bywurke wurdt of it adres fan ’e gast feroaret.