Miért nem működik a PAC-proxy a vendég VM-ben a gazdagép URL-jével

„A gazdagép ezt a PAC-fájlt használja, ezért ugyanezt az URL-t tettem a VM-be” értelmes mondat és hiányos terv. A PAC URL egy házirend-szkriptre mutat, nem proxyra. Amíg a vendég nem tudja letölteni azt a szkriptet, a vendég saját címeivel kiértékelni, majd elérni bármely proxyt, amelyet a szkript megnevez, az URL csak egy karakterlánc egy beállításmezőben. A virtuális gépek proxyházirendje körüli zavar nagy része abból ered, hogy ezt az egy sort tekintik a teljes konfigurációnak.

A PAC URL szkript, nem proxy

A fájl egy függvényt tartalmaz, amely egy URL-t és egy gazdagépet vesz fel, és proxy-leírást vagy a DIRECT szót adja vissza. Semmi sem mondja meg az URL-ben az alkalmazásnak, hová küldje a forgalmat; ez a döntés futásidőben, a szkripten belül születik, olyan adatokkal, amelyeket a szkript a platformtól kér. Egy beállítási párbeszéd, amely PAC URL-t fogad el, egy döntési eljárásra mutató hivatkozást fogad el.

Ez a különbség az oka annak, hogy az URL másolása úgy tűnhet, működött. A mező kitöltődik, a beállítás mentődik, és a hiba csak később jelenik meg, amikor a szkript nem tölthető le, vagy amikor olyan proxyt ad vissza, amelyet a vendég nem ér el.

A négy lépés mindegyike másképp hiúsul meg

A vendégben négy dolognak kell sorrendben megtörténnie, és mindegyiknek megvan a maga hibajellegzetessége. A vendég letölti a PAC-fájlt. Az alkalmazás kiértékeli a szkriptet a kért URL-re helyi információkkal. A kiválasztott proxy feloldódik, és elérhetővé válik. Hitelesítés történik, ha a proxy megköveteli.

Kezdje a letöltés bizonyításával, mert anélkül minden további értelmetlen. Egy privát kiszolgálón lévő PAC-fájlhoz engedélyezett útvonal kell ahhoz a kiszolgálóhoz, mielőtt bármely szabály segíthetne, és egy elérhetetlen szkripten belüli proxyválasztás nem hozhatja létre azt az útvonalat, amely letöltené:

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

Ha ez a kérés a vendégből meghiúsul és a gazdagépből működik, a probléma a vendég útvonala a PAC kiszolgálóhoz, nem a szkript tartalma. Ha JavaScript-fájlt ad vissza, lépjen a második lépésre, és derítse ki, mit dönt a szkript a vendég környezetére.

Ugyanaz a szkript a VM-en belül másképp dönt

A PAC-függvények megvizsgálhatják a kért gazdagépet és a kiértékelést végző gépre vonatkozó információkat. Az ügyfél saját címére épülő szabály, például amely egy interfészcímet vagy egy alhálózathoz tartozást ellenőriz, a vendég címét fogja látni, nem a fizikai gazdagépét. A gazdagép oldali NAT mögött ezek különböző címek, ezért ugyanaz a szkript más proxyt választhat, vagy a VM-en belül visszaeshet a DIRECT-re.

Ez nem hiba a szkriptben. A szkript pontosan azt teszi, amire írták, más bemenettel, és ez magyarázza a zavarba ejtő jelentést, amelyben a gazdagép a proxyt használja, a vendég pedig közvetlenül kapcsolódik. Reprodukálja a döntést ahelyett, hogy érvelne róla: egy PAC-kiértékelő, amely címet és URL-t vesz fel, ha a disztribúciója tartalmaz ilyet, egyetlen paranccsal eldönti a kérdést. Ellenkező esetben azzal az alkalmazással teszteljen, amelyet valóban használni fognak, és olvassa a proxy naplóját ahelyett, hogy találgatna.

Ne következtessen arra, hogy a vendég örökölte a gazdagép proxybeállításait mert a forgalma a gazdagép oldali fordításon halad át. A hálózati fordítás továbbítja a csomagokat; nem másolja az alkalmazáskonfigurációt, és a rendszerproxy alkalmazáskonfiguráció.

Eszközök, amelyek egyáltalán nem olvassák a PAC-ot

A parancssori eszközök külön határvonalat jelentenek, és itt sok idő megy el. A curl nem hajt végre PAC-fájlokat, ahogyan a proxy dokumentációja világosan mondja. Ha egy proxyváltozót a PAC letöltési URL-jére állítunk, a szkript nem válik proxyvégponttá; az eszköz HTTP-t próbál beszélni egy JavaScript-fájllal, és olyan módon hiúsul meg, amely hálózati problémának tűnik.

Ugyanez vonatkozik sok csomagkezelőre, nyelvi futtatókörnyezetre és build-eszközre, amelyek csak a kifejezett proxyváltozókat vagy a saját konfigurációjukat tisztelik. Ha a vizsgálat, amely érdekli, egy CLI-eszköz, konfigurálja a konkrét proxyval, amelyet a PAC-szkript választott volna, és jegyezze fel, hogyan jutott erre a választásra, hogy a következő ember megismételhesse.

Linuxos asztali alkalmazások esetén a rendszerbeállítást automatikus módba kell állítani, és URL-t is kell adni neki; egy URL, amelyet még kézi módban mentenek, semmit sem tesz. Ellenőrizze mindkettőt, és ellenőrizze őket a vendégen belül:

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

A DIRECT is döntés

A DIRECT PAC-eredmény azt jelenti, hogy az alkalmazás megkerüli a HTTP-proxyt, nem azt, hogy kiszökött a hálózatból. A kapott kapcsolat továbbra is követhet egy operációsrendszer-útvonalat egy alagúton keresztül, vagy meghiúsulhat olyan okokból, amelyeknek semmi közük a proxyhasználathoz. Fordítva, egy proxyeredmény egy alkalmazás kérését írja le, nem a vendég minden folyamatát.

Tehát abban az irányban ellenőrizzen, amelyben a követelményt megírták. Ha a követelmény az, hogy „ez az alkalmazás eléri a belső oldalt”, bizonyítsa, hogy ez az alkalmazás eléri, és jegyezze fel, melyik proxy vagy útvonal vitte. Ha a követelmény az, hogy „a VM a vállalati hálózaton van”, egy kiválasztott proxyn keresztül működő böngésző bizonyíték arra a böngészőre, és semmi többre.

Javítsa a láncot a vendégen belül, ahelyett hogy kikapcsolná a gazdagép alagútját vagy lazítaná a továbbítási házirendet, hogy egy teszt átmenjen. A láncnak négy szeme van, és egy olyan változtatás, amely kihagy egyet közülük, addig tart, amíg legközelebb frissítik a szkriptet, vagy megváltozik a vendég címe.