Mac VPN in PAC proxy: dve odločitvi, ne ena nastavitev
Datoteka PAC izbere proxy za vsako zahtevo, medtem ko VPN izbere pot. Spremljajte prenos, izbiro in vtičnico ter prenehajte brati DIRECT kot brez povezave.
Vaš Mac prenese skript politike in nato ta skript vpraša, kateri posrednik naj ga zahteva uporabi, medtem ko tunel odloča le o tem, kako se doseže izbrani skok. Oba odgovora pristaneta na isti vtičnici, zato je zahteva, ki spodleti potem, ko sta oba uspela, videti kot ena okvara, čeprav sta dve. Ločevanje prenosa od izbire in izbire od poti je večina dela v teh zahtevah. Spodnji vrstni red sledi temu, kar macOS v resnici počne, s preverjanji, ki naredijo vsako stopnjo vidno.
Kje se naslov PAC in proxy razideta
Naslov, kot je https://config.corp.example/proxy.pac, poimenuje dokument za prenos, ta dokument pa poimenuje strežnik, skozi katerega gre promet. Prilepitev URL-ja v polje gostitelja proxy prosi odjemalca, da odpre proxy povezavo do strežnika datotek, ki takšne povezave nikoli ne posluša. V datoteki je funkcija, ki jo odjemalec pokliče pri vsaki zahtevi, in njena vrnjena vrednost je naslednji skok za to eno ciljno mesto. Ta posrednost pojasnjuje, zakaj se lahko dva računalnika v isti omrežni storitvi obnašata različno, čeprav imata oba pravilen URL. Pojasnjuje tudi, zakaj sprememba politike začne veljati, ne da bi se kdo dotaknil samega proxyja.
Preberite skript, preden karkoli razlagate naprej, ker pravila v njem nosijo izjeme organizacije in vrstni red njihove uporabe. Zgodnje široko območje lahko zasenči poznejšo notranjo pripono in gostitelj, ki bi očitno moral obiti proxy, ga še naprej uporablja. Ko kdo vztraja, da so pravila napačna, je skript edino mesto, kjer se ta trditev razreši.
Skript je treba pridobiti, preden karkoli odloči
Prenos politike zahteva razrešeno ime in pot do tega, kar streže datoteko, povezan tunel pa ne zagotavlja ne enega ne drugega. Če se gostitelj razrešuje le prek zasebnega DNS, takrat uporabljeni reševalnik odloči, ali se prenos lahko začne. Če je gostitelj v zasebnem obsegu, mora pot obstajati s tega računalnika, ne s prenosnika sodelavca. Kopija, shranjena v predpomnilniku prejšnje seje, vse to skrije, dokler predpomnilnik ne poteče ali se računalnik znova zažene.
Izvedite tri preverjanja spodaj po vrstnem redu in se ustavite pri prvi napaki, ker stopnje nimajo skupnega vzroka. Skupaj pokažejo, ali je politika nastavljena, ali je dosegljiva in kaj vrne.
scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac
Prvi ukaz izpiše slovar proxy za aktivno storitev, vključno z vsakim URL-jem samodejne konfiguracije, ki ga ima sistem. Drugi poroča o URL-ju, vezanem na eno imenovano storitev, kar je pomembno na prenosniku, ki se giblje med Wi-Fi in Ethernet. Tretji pridobi datoteko brez upodabljanja, zato 404, časovna omejitev in napaka reševalnika ostanejo razločljivi. Če zadnji ukaz vrne skript, medtem ko aplikacije še vedno odpovedujejo, je težava že presegla pridobivanje.
Kaj odgovor DIRECT v resnici preskoči
Specifikacija PAC odjemalcu ponudi majhen besednjak, in DIRECT je ena od njegovih besed. Beseda odjemalcu pove, naj pri tej zahtevi preskoči proxy, in ne pove nič o tem, kateri vmesnik bo vtičnica nato uporabila. Neposredna vtičnica na polnem tunelu vseeno izide skozi VPN in cilju vseeno pokaže izhodni naslov tunela.
Branje DIRECT kot nekaj zunaj VPN je napaka, ki ljudi pošlje na napačno ploščo z nastavitvami. Zrcalna slika je prav tako pogosta, ker je do zasebnega proxyja mogoče priti po razdeljeni poti, medtem ko preostanek računalnika ostane zunaj tunela. Kar cilj takrat poroča, pripada lastnemu izhodu proxyja, ki je lahko v drugi državi. Zapis pričakovanja za enega notranjega in enega javnega gostitelja to hitro razkrije, saj skript pogosto odgovori obema različno. Ko veste, kateri skok je ustvaril naslov, poročilo neha biti skrivnostno.
Tri napake, ki se pojavijo kot ena stran z napako
Politika se morda ne prenese, izbrani proxy morda ni dosegljiv in zahteva, ki prispe do storitve, je tam lahko še vedno zavrnjena. Vse tri prispejo kot časovna omejitev ali splošna stran z napako in nobena ne poimenuje stopnje, ki se je zlomila. Zajetje odločitve ob napaki je tisto, kar jih loči. Dve sondi spodaj preizkusita skok, ki ga je izbral skript, eno za vsako vejo, ki jo lahko vrne.
curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/
Dokončana povezava s proxyjem premakne vprašanje na preverjanje pristnosti ali na lastno politiko proxyja, ki ima drugega lastnika. Dokončana povezava z notranjim gostiteljem brez proxyja na poti izključi pot in pokaže na politiko. Oba ukaza ignorirata slovar proxy v macOS, razen če lupina izvozi spremenljivke proxy, zato jih najprej počistite. Nobena sonda ne dokaže druge, zato ena stran z napako tako dolgo zavaja.
Kaj predati skupaj z zahtevkom
Pošljite aktivno omrežno storitev, URL PAC, rezultat ocene za gostitelja, ki odpoveduje, in stopnjo, na kateri se je pojavila napaka. Ti štirje omogočijo naslednji osebi, da odločitev ponovi, namesto da ugiba, katera plast je bila vpletena. Dodajte stanje tunela v trenutku preizkusa, ker je rezultat, zajet pred ponovno povezavo, zastarel. Shranite tudi revizijo skripta, saj se datoteka politike spreminja brez obvestila in včerajšnji odgovor morda ni več veljaven.
Zabeležite, kako se odjemalec obnaša, ko skripta ni mogoče pridobiti, ker se izvedbe razlikujejo in odločitev o proxyju ni celotna naprava izklop. Nekateri se vrnejo na neposredno povezavo, drugi odpovedo zaprti, in ta razlika spremeni, ali je izpad videti kot pokvarjen proxy ali kot delujoča politika. Potrdite obnašanje za točnega odjemalca in različico, preden se med incidentom zanesete nanj.