Macin VPN ja PAC-välityspalvelin: kaksi päätöstä, ei yksi asetus

Macisi lataa käytäntöskriptin ja kysyy sitten siltä skriptiltä, mitä välittäjää pyynnön tulisi käyttää, kun taas tunneli päättää vain, miten valittuun hyppyyn päästään. Molemmat vastaukset päätyvät samaan sockettiin, joten pyyntö, joka epäonnistuu molempien onnistuttua, näyttää yhdeltä vialta, vaikka niitä on kaksi. Latauksen erottaminen valinnasta ja valinnan erottaminen reitistä on suurin osa näiden tikettien työstä. Alla oleva järjestys seuraa sitä, mitä macOS todella tekee, sekä tarkistuksia, jotka tekevät jokaisen vaiheen näkyväksi.

Missä PAC-osoite ja välityspalvelin eroavat

Osoite kuten https://config.corp.example/proxy.pac nimeää ladattavan asiakirjan, ja tämä asiakirja nimeää palvelimen, jonka kautta liikenne kulkee. URL:n liittäminen välityspalvelimen isäntäkenttään pyytää asiakasta avaamaan välityspalvelinyhteyden tiedostopalvelimeen, joka ei koskaan kuuntele sellaista. Tiedoston sisällä on funktio, jota asiakas kutsuu jokaista pyyntöä kohden, ja sen paluuarvo on seuraava hyppy juuri sille yhdelle kohteelle. Tämä epäsuoruus selittää, miksi kaksi konetta samassa verkkopalvelussa voivat käyttäytyä eri tavoin, vaikka molemmilla on oikea URL. Se selittää myös, miksi käytännön muutos tulee voimaan kenenkään koskematta itse välityspalvelimeen.

Lue skripti ennen kuin tulkitset mitään alavirrassa, sillä sen sisältämät säännöt kantavat organisaation poikkeukset ja niiden soveltamisjärjestyksen. Varhainen laaja alue voi peittää myöhemmän sisäisen suffiksin, ja isäntä, jonka pitäisi selvästi ohittaa välityspalvelin, käyttää sitä edelleen. Kun joku väittää käytännön olevan väärä, skripti on ainoa paikka, jossa väite ratkaistaan.

Skripti on haettava ennen kuin se päättää mitään

Käytännön lataaminen vaatii ratkaistun nimen ja reitin siihen, mikä tiedostoa palvelee, eikä yhdistetty tunneli takaa kumpaakaan. Jos isäntä ratkaistaan vain yksityisen DNS:n kautta, sillä hetkellä käytössä oleva ratkaisija päättää, voiko lataus alkaa. Jos isäntä on yksityisellä alueella, reitin on oltava tästä koneesta, ei kollegan kannettavasta. Aiemmassa istunnossa välimuistiin tallennettu kopio piilottaa kaiken tämän, kunnes välimuisti vanhenee tai kone käynnistetään uudelleen.

Suorita alla olevat kolme tarkistusta järjestyksessä ja pysähdy ensimmäiseen epäonnistumiseen, sillä vaiheilla ei ole yhteistä syytä. Yhdessä ne näyttävät, onko käytäntö määritetty, onko se tavoitettavissa ja mitä se palauttaa.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

Ensimmäinen komento tulostaa aktiivisen palvelun välityspalvelinsanakirjan, mukaan lukien kaikki automaattisen määrityksen URL, jonka järjestelmä pitää. Toinen raportoi yhteen nimettyyn palveluun liitetyn URL:n, millä on merkitystä kannettavassa, joka liikkuu Wi-Fin ja Ethernetin välillä. Kolmas hakee tiedoston sitä renderöimättä, joten 404, aikakatkaisu ja ratkaisijan virhe pysyvät erotettavina. Jos viimeinen komento palauttaa skriptin sovellusten yhä epäonnistuessa, ongelma on jo ohittanut haun.

Mitä DIRECT-vastaus todella ohittaa

PAC-määrittely antaa asiakkaalle pienen sanaston, ja DIRECT on yksi sen sanoista. Sana käskee asiakasta ohittaa välityspalvelin kyseisen pyynnön osalta eikä kerro mitään siitä, mitä liitäntää socketti sen jälkeen käyttää. Suora socketti täydessä tunnelissa lähtee silti VPN:n kautta ja näyttää silti tunnelin ulostulo-osoitteen kohteelle.

DIRECT:n lukeminen VPN:n ulkopuolelle kuuluvana on virhe, joka lähettää ihmiset väärään asetusruutuun. Peilikuva on yhtä yleinen, sillä yksityiseen välityspalvelimeen voi päästä jaetun reitin kautta, kun muu kone jää tunnelin ulkopuolelle. Se, mitä kohde silloin raportoi, kuuluu välityspalvelimen omaan lähtöön, joka voi sijaita toisessa maassa. Odotuksen kirjoittaminen yhdelle sisäiselle ja yhdelle julkiselle isännälle paljastaa tämän nopeasti, sillä skripti vastaa usein näille kahdelle eri tavoin. Kun tiedät, mikä hyppy tuotti osoitteen, raportti lakkaa olemasta salaperäinen.

Kolme epäonnistumista, jotka näyttäytyvät yhtenä virhesivuna

Käytäntö voi epäonnistua latautumaan, valittu välityspalvelin voi olla tavoittamaton, ja palveluun saapuva pyyntö voidaan silti hylätä siellä. Kaikki kolme saapuvat aikakatkaisuna tai yleisenä virhesivuna, eikä mikään nimeä vaihetta, joka rikkoutui. Päätöksen tallentaminen virheen viereen on se, mikä erottaa ne. Alla olevat kaksi koetinta testaavat hypyn, jonka skripti valitsi, yksi kullekin haaralle, jonka se voi palauttaa.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Valmis yhteys välityspalvelimeen siirtää kysymyksen todentamiseen tai välityspalvelimen omaan käytäntöön, jolla on eri omistaja. Valmis yhteys sisäiseen isäntään ilman välityspalvelinta polulla sulkee pois reitin ja osoittaa käytäntöön. Molemmat komennot jättävät macOS:n välityspalvelinsanakirjan huomiotta, ellei kuori vie välityspalvelinmuuttujia, joten tyhjennä ne ensin. Kumpikaan koetin ei todista toista, minkä vuoksi yksi virhesivu johtaa harhaan niin kauan.

Mitä tiketin mukana luovutetaan

Lähetä aktiivinen verkkopalvelu, PAC-URL, epäonnistuvan isännän arviointitulos ja vaihe, jossa virhe ilmeni. Nämä neljä antavat seuraavalle henkilölle mahdollisuuden toistaa päätöksen sen sijaan, että hän arvaisi, mikä kerros oli mukana. Lisää tunnelin tila testin hetkellä, sillä ennen uudelleenyhdistämistä tallennettu tulos on vanhentunut. Säilytä myös skriptin revisio, sillä käytäntötiedosto muuttuu ilman ilmoitusta ja eilinen vastaus ei ehkä enää pidä paikkaansa.

Kirjaa, miten asiakas käyttäytyy, kun skriptiä ei voi hakea, sillä toteutukset eroavat eikä välityspalvelinpäätös ole koko laitteen hätäkatkaisin. Jotkut palaavat suoraan yhteyteen ja toiset epäonnistuvat suljetusti, ja tämä ero muuttaa sitä, näyttääkö katkos rikkinäiseltä välityspalvelimelta vai toimivalta käytännöltä. Vahvista käyttäytyminen täsmälliselle asiakkaalle ja versiolle ennen kuin luotat siihen häiriön aikana.