Miksi PAC-välityspalvelin vieraana olevassa VM:ssä epäonnistuu isännän URLilla

”Isäntä käyttää tätä PAC-tiedostoa, joten laitoin saman URLin VM:ään” on järkevä lause ja puutteellinen suunnitelma. PAC-URL osoittaa käytäntöskriptiin, ei välityspalvelimeen. Kunnes vieras voi noutaa kyseisen skriptin, arvioida sen vieraan omilla osoitteilla ja saavuttaa sitten minkä tahansa välityspalvelimen, jonka skripti nimeää, URL on vain merkkijono asetuskentässä. Suurin osa virtuaalikoneiden välityspalvelinkäytännön ympärillä olevasta sekaannuksesta syntyy siitä, että tuota yhtä riviä pidetään koko kokoonpanona.

PAC-URL on skripti, ei välityspalvelin

Tiedosto sisältää funktion, joka ottaa URLin ja isännän ja palauttaa välityspalvelimen kuvauksen tai sanan DIRECT. Mikään URLissa ei kerro sovellukselle, minne liikenne lähetetään; päätös tehdään suorituksen aikana, skriptin sisällä, tiedoilla, joita skripti pyytää alustalta. Asetusikkuna, joka hyväksyy PAC-URLin, hyväksyy osoittimen päätösmenettelyyn.

Juuri tämä ero selittää, miksi URLin kopioiminen voi näyttää onnistuneen. Kenttä täytetään, asetus tallennetaan, ja virhe näkyy vasta myöhemmin, kun skriptiä ei voi noutaa tai kun se palauttaa välityspalvelimen, johon vieras ei pääse.

Neljä vaihetta epäonnistuvat kukin eri tavalla

Vieraan sisällä neljän asian on tapahduttava järjestyksessä, ja jokaisella on oma virheallekirjoituksensa. Vieras noutaa PAC-tiedoston. Sovellus arvioi skriptin pyydetylle URLille paikallisia tietoja käyttäen. Valittu välityspalvelin selvitetään ja saavutetaan. Todennus tapahtuu, jos välityspalvelin vaatii sen.

Aloita todistamalla nouto, sillä ilman sitä kaikki seuraava on merkityksetöntä. Yksityisellä palvelimella oleva PAC-tiedosto vaatii sallitun polun kyseiselle palvelimelle ennen kuin mikään sääntö voi auttaa, eikä saavuttamattoman skriptin sisällä tehty välityspalvelinvalinta voi luoda polkua, joka sen noutaisi:

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

Jos pyyntö epäonnistuu vieraasta ja toimii isännästä, ongelma on vieraan polku PAC-palvelimelle, ei skriptin sisältö. Jos se palauttaa JavaScript-tiedoston, siirry toiseen vaiheeseen ja selvitä, mitä skripti päättää vieraan kontekstille.

Sama skripti päättää VM:n sisällä toisin

PAC-funktiot voivat tarkastella pyydettyä isäntää ja tietoja koneesta, joka suorittaa arviointia. Asiakkaan omaan osoitteeseen rakennettu sääntö, esimerkiksi sellainen, joka tarkistaa liittymän osoitteen tai aliverkkokuulumisen, näkee vieraan osoitteen eikä fyysisen isännän osoitetta. Isännän puolen NATin takana nämä ovat eri osoitteita, joten sama skripti voi valita toisen välityspalvelimen tai pudota DIRECTiin VM:n sisällä.

Tämä ei ole skriptin vika. Skripti tekee täsmälleen sen, mitä varten se kirjoitettiin, eri syötteellä, ja se selittää hämmentävän raportin, jossa isäntä käyttää välityspalvelinta ja vieras yhdistää suoraan. Toista päätös sen sijaan että järkeilisit sitä: PAC-arvioija, joka ottaa osoitteen ja URLin, jos jakelusi sisältää sellaisen, ratkaisee kysymyksen yhdellä komennolla. Muuten testaa sovelluksella, jota todella käytetään, ja lue sen välityspalvelinloki sen sijaan että arvaisit.

Älä päättele, että vieras on perinyt isännän välityspalvelinasetukset koska sen liikenne kulkee isännän puolen käännöksen kautta. Verkkokäännös välittää paketteja; se ei kopioi sovellusten kokoonpanoa, ja järjestelmän välityspalvelin on sovelluksen kokoonpano.

Työkalut, jotka eivät lue PACia lainkaan

Komentorivityökalut ovat erillinen raja, ja juuri siellä kuluu paljon aikaa. curl ei suorita PAC-tiedostoja, kuten sen välityspalvelindokumentaatio sanoo suoraan. Välityspalvelinmuuttujan osoittaminen PAC-latauksen URLiin ei tee skriptistä välityspalvelimen päätepistettä; työkalu yrittää puhua HTTP:tä JavaScript-tiedoston kanssa ja epäonnistuu tavalla, joka näyttää verkkohäiriöltä.

Sama koskee monia paketinhallintaohjelmia, kielten suoritusympäristöjä ja rakennustyökaluja, jotka noudattavat vain nimenomaisia välityspalvelinmuuttujia tai omaa kokoonpanoaan. Jos testi, josta välität, on CLI-työkalu, määritä se konkreettisella välityspalvelimella, jonka PAC-skripti olisi valinnut, ja kirjaa, miten päädyit siihen valintaan, jotta seuraava ihminen voi toistaa sen.

Linuxin työpöytäsovelluksissa järjestelmäasetus on asetettava automaattiseen tilaan ja sille on annettava myös URL; URL, joka tallennetaan tilan ollessa vielä manuaalinen, ei tee mitään. Tarkista molemmat ja tarkista ne vieraan sisällä:

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

DIRECT on myös päätös

PAC-tulos DIRECT tarkoittaa, että sovellus ohittaa HTTP-välityspalvelimen, ei sitä että se olisi paennut verkosta. Syntyvä yhteys voi silti seurata käyttöjärjestelmän reittiä tunnelin läpi tai epäonnistua syistä, joilla ei ole mitään tekemistä välityspalvelimen käytön kanssa. Päinvastoin, välityspalvelintulos kuvaa yhden sovelluksen pyyntöä, ei jokaista vieraan prosessia.

Tarkista siis siihen suuntaan, johon vaatimus on kirjoitettu. Jos vaatimus on ”tämä sovellus saavuttaa sisäisen sivuston”, osoita että kyseinen sovellus saavuttaa, ja merkitse, mikä välityspalvelin tai reitti sen kuljetti. Jos vaatimus on ”VM on yritysverkossa”, valitun välityspalvelimen kautta toimiva selain on todiste kyseiselle selaimelle eikä mitään muuta.

Korjaa ketju vieraan sisällä sen sijaan että sammuttaisit isännän tunnelin tai löysäisit edelleenlähetyskäytäntöä testin läpäisemiseksi. Ketjussa on neljä lenkkiä, ja muutos, joka ohittaa yhden niistä, kestää seuraavaan kertaan, jolloin skripti päivitetään tai vieraan osoite muuttuu.