Kodėl PAC tarpinis serveris svečio VM neveikia su hosto URL

„Hostas naudoja šį PAC failą, todėl įdėjau tą patį URL į VM“ yra pagrįstas sakinys ir nepilnas planas. PAC URL nurodo politikos scenarijų, o ne tarpinį serverį. Kol svečias negali gauti to scenarijaus, įvertinti jo savo adresais ir tada pasiekti bet kurį scenarijaus įvardytą tarpinį serverį, URL tebėra tik eilutė nustatymų lauke. Didžioji dalis painiavos dėl tarpinio serverio politikos virtualiose mašinose kyla dėl to, kad ta viena eilutė laikoma visa konfigūracija.

PAC URL yra scenarijus, o ne tarpinis serveris

Faile yra funkcija, kuri priima URL ir hostą ir grąžina tarpinio serverio aprašą arba žodį DIRECT. Niekas URL nieko nesako programai, kur siųsti srautą; šis sprendimas priimamas vykdymo metu, scenarijaus viduje, naudojant duomenis, kurių scenarijus prašo iš platformos. Nustatymų dialogas, priimantis PAC URL, priima rodyklę į sprendimo procedūrą.

Būtent šis skirtumas paaiškina, kodėl URL kopijavimas gali atrodyti sėkmingas. Laukas užpildomas, nustatymas išsaugomas, o gedimas pasirodo tik vėliau, kai scenarijaus neįmanoma gauti arba kai jis grąžina tarpinį serverį, kurio svečias negali pasiekti.

Keturi žingsniai nepavyksta kiekvienas savaip

Svečio viduje turi įvykti keturi dalykai iš eilės, ir kiekvienas turi savo klaidos požymį. Svečias gauna PAC failą. Programa įvertina scenarijų prašomam URL naudodama vietinę informaciją. Pasirinktas tarpinis serveris išsprendžiamas ir pasiekiamas. Autentifikacija vyksta, jei tarpinis serveris to reikalauja.

Pradėkite nuo gavimo įrodymo, nes be jo visa kita neturi prasmės. PAC failas privačiame serveryje reikalauja leidžiamo kelio į tą serverį, kol bet kuri taisyklė gali padėti, o tarpinio serverio pasirinkimas nepasiekiamame scenarijuje negali sukurti kelio, kuris jį gautų:

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

Jei ši užklausa nepavyksta iš svečio ir veikia iš hosto, problema yra svečio kelias į PAC serverį, o ne scenarijaus turinys. Jei jis grąžina JavaScript failą, pereikite prie antro žingsnio ir išsiaiškinkite, ką scenarijus nusprendžia svečio kontekstui.

Tas pats scenarijus VM viduje nusprendžia kitaip

PAC funkcijos gali tikrinti prašomą hostą ir informaciją apie mašiną, kuri atlieka vertinimą. Taisyklė, sukurta pagal paties kliento adresą, pavyzdžiui, tikrinanti sąsajos adresą ar priklausymą potinkliui, matys svečio adresą, o ne fizinio hosto. Už hosto pusės NAT tai skirtingi adresai, todėl tas pats scenarijus gali pasirinkti kitą tarpinį serverį arba VM viduje grįžti prie DIRECT.

Tai ne scenarijaus klaida. Scenarijus daro būtent tai, kam buvo parašytas, su kitokiu įėjimu, ir tai paaiškina painų pranešimą, kuriame hostas naudoja tarpinį serverį, o svečias jungiasi tiesiogiai. Atkurkite sprendimą, o ne samprotaukite apie jį: PAC vertintuvas, priimantis adresą ir URL, jei jūsų distribucija tokį turi, išsprendžia klausimą viena komanda. Priešingu atveju testuokite su programa, kuri iš tikrųjų bus naudojama, ir skaitykite jos tarpinio serverio žurnalą, o ne spėliokite.

Nedarikite išvados, kad svečias paveldėjo hosto tarpinio serverio nustatymus nes jo srautas eina per hosto pusės vertimą. Tinklo vertimas persiunčia paketus; jis nenukopijuoja programų konfigūracijos, o sistemos tarpinis serveris yra programos konfigūracija.

Įrankiai, kurie visiškai neskaito PAC

Komandų eilutės įrankiai yra atskira riba, ir būtent čia prarandama daug laiko. curl nevykdo PAC failų, kaip jo tarpinio serverio dokumentacija aiškiai sako. Tarpinio serverio kintamojo nukreipimas į PAC atsisiuntimo URL nepaverčia scenarijaus tarpinio serverio galutiniu tašku; įrankis bandys kalbėtis HTTP su JavaScript failu ir nepavyks taip, kad atrodys kaip tinklo problema.

Tas pats galioja daugeliui paketų tvarkytuvų, kalbų vykdymo aplinkų ir kūrimo įrankių, kurie gerbia tik aiškius tarpinio serverio kintamuosius arba savo konfigūraciją. Jei testas, kuris jums rūpi, yra CLI įrankis, sukonfigūruokite jį su konkrečiu tarpiniu serveriu, kurį būtų pasirinkęs PAC scenarijus, ir užsirašykite, kaip priėjote prie šio pasirinkimo, kad kitas žmogus galėtų jį pakartoti.

Linux darbalaukio programoms sistemos nustatymas turi būti perjungtas į automatinį režimą ir jam turi būti duotas URL; URL, išsaugotas kol režimas dar rankinis, nieko nedaro. Patikrinkite abu ir patikrinkite juos svečio viduje:

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

DIRECT taip pat yra sprendimas

PAC rezultatas DIRECT reiškia, kad programa apeina HTTP tarpinį serverį, o ne kad ji pabėgo iš tinklo. Gautas ryšys vis tiek gali eiti operacinės sistemos maršrutu per tunelį arba nepavykti dėl priežasčių, nesusijusių su tarpinio serverio naudojimu. Atvirkščiai, tarpinio serverio rezultatas aprašo vienos programos užklausą, o ne kiekvieną svečio procesą.

Todėl tikrinkite ta kryptimi, kuria buvo parašytas reikalavimas. Jei reikalavimas yra „ši programa pasiekia vidinę svetainę“, įrodykite, kad ta programa pasiekia, ir užsirašykite, kuris tarpinis serveris ar maršrutas ją pernešė. Jei reikalavimas yra „VM yra įmonės tinkle“, naršyklė, veikianti per pasirinktą tarpinį serverį, yra tos naršyklės įrodymas ir nieko daugiau.

Sutaisykite grandinę svečio viduje, o ne išjunkite hosto tunelį ar sušvelninkite persiuntimo politiką, kad testas praeitų. Grandinė turi keturias grandis, o pakeitimas, praleidžiantis vieną iš jų, laikysis iki kito karto, kai scenarijus bus atnaujintas arba pasikeis svečio adresas.