Mac VPN i PAC proxy: dvije odluke, a ne jedna postavka

Vaš Mac preuzima skriptu pravila i zatim tu skriptu pita koji posrednik treba koristiti za zahtjev, dok tunel odlučuje samo kako se dolazi do odabranog skoka. Oba odgovora završavaju na istom socketu, pa zahtjev koji padne nakon što su oba uspjela izgleda kao jedna greška kad su dvije. Razdvajanje preuzimanja od odabira i odabira od rute čini većinu posla u ovim ticketima. Redoslijed ispod slijedi ono što macOS zapravo radi, s provjerama koje svaki korak čine vidljivim.

Gdje se PAC adresa i proxy razilaze

Adresa poput https://config.corp.example/proxy.pac imenuje dokument za preuzimanje, a taj dokument imenuje poslužitelj kroz koji ide promet. Lijepljenje URL-a u polje hosta proxyja traži od klijenta da otvori proxy vezu prema datotečnom poslužitelju koji takvu vezu nikada ne sluša. Unutar datoteke je funkcija koju klijent poziva za svaki zahtjev, a njezina povratna vrijednost je sljedeći skok za tu jedinu destinaciju. Ta neizravnost objašnjava zašto se dva računala na istoj mrežnoj usluzi mogu ponašati različito iako oba imaju ispravan URL. Objašnjava i zašto promjena pravila stupa na snagu bez toga da itko dira sam proxy.

Pročitajte skriptu prije nego što bilo što protumačite nizvodno, jer pravila u njoj nose iznimke organizacije i redoslijed njihove primjene. Rani široki raspon može zasjeniti kasniji interni sufiks i host koji očito treba zaobići proxy nastavlja ga koristiti. Kad netko tvrdi da su pravila pogrešna, skripta je jedino mjesto gdje se ta tvrdnja rješava.

Skripta se mora dohvatiti prije nego što bilo što odluči

Preuzimanje pravila traži razriješeno ime i rutu do onoga što poslužuje datoteku, a spojen tunel ne jamči ni jedno. Ako se host razrješava samo preko privatnog DNS-a, resolver koji je u tom trenutku u upotrebi odlučuje može li preuzimanje početi. Ako se host nalazi na privatnom rasponu, ruta mora postojati s ovog računala, a ne s kolegina prijenosnika. Kopija keširana tijekom ranije sesije skriva sve to dok keš ne istekne ili se računalo ne pokrene iznova.

Pokrenite tri provjere u nastavku redom i zaustavite se na prvom neuspjehu, jer koraci ne dijele isti uzrok. Zajedno pokazuju je li pravilo konfigurirano, je li dostupno i što vraća.

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

Prva naredba ispisuje rječnik proxyja za aktivnu uslugu, uključujući svaki URL automatske konfiguracije koji sustav drži. Druga izvješćuje URL pridružen jednoj imenovanoj usluzi, što je važno na prijenosniku koji prelazi između Wi-Fi i Ethernet. Treća dohvaća datoteku bez njezina iscrtavanja, pa 404, istek vremena i neuspjeh resolvera ostaju razlučivi. Ako ta posljednja naredba vrati skriptu, a aplikacije i dalje ne rade, problem je već prešao dohvaćanje.

Što odgovor DIRECT zapravo preskače

Specifikacija PAC daje klijentu mali rječnik i DIRECT je jedna riječ iz njega. Ta riječ kaže klijentu da preskoči proxy za taj zahtjev i ne govori ništa o tome koje će sučelje socket zatim koristiti. Izravni socket na punom tunelu ipak izlazi kroz VPN i ipak pokazuje izlaznu adresu tunela destinaciji.

Čitanje DIRECT kao nečega izvan VPN-a pogreška je koja ljude šalje na pogrešan panel postavki. Zrcalna slika jednako je česta, jer se do privatnog proxyja može doći preko podijeljene rute dok ostatak računala ostaje izvan tunela. Ono što destinacija tada prijavljuje pripada vlastitom izlazu proxyja, koji može biti u drugoj zemlji. Zapisivanje očekivanja za jedan interni host i jedan javni host brzo to razotkriva, jer skripta često odgovara na njih dvoje različito. Kad znate koji je skok proizveo adresu, izvještaj prestaje biti zagonetan.

Tri greške koje se pojavljuju kao jedna stranica pogreške

Pravilo se možda neće preuzeti, odabrani proxy možda nije dostupan, a zahtjev koji stigne do usluge može ondje biti odbijen. Sva tri dolaze kao istek vremena ili opća stranica pogreške i nijedno ne imenuje korak koji se slomio. Bilježenje odluke uz pogrešku ono je što ih razdvaja. Dvije sonde u nastavku testiraju skok koji je skripta odabrala, po jednu za svaku granu koju može vratiti.

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

Dovršena veza s proxyjem prenosi pitanje na autentikaciju ili na vlastita pravila proxyja, koja imaju drugog vlasnika. Dovršena veza s internim hostom bez proxyja na putu isključuje rutu i upućuje na pravila. Obje naredbe ignoriraju rječnik proxyja u macOS-u osim ako ljuska izvozi proxy varijable, pa ih prvo očistite. Nijedna sonda ne dokazuje drugu, i zato jedna stranica pogreške toliko dugo zavodi.

Što predati uz ticket

Pošaljite aktivnu mrežnu uslugu, PAC URL, rezultat evaluacije za host koji ne radi i korak u kojem se pojavila pogreška. Ta četiri omogućuju sljedećoj osobi da reproducira odluku umjesto da nagađa koji je sloj bio uključen. Dodajte stanje tunela u trenutku testa, jer je rezultat zabilježen prije ponovnog spajanja zastario. Sačuvajte i reviziju skripte, jer se datoteka pravila mijenja bez najave i jučerašnji odgovor možda više nije aktualan.

Zabilježite kako se klijent ponaša kada se skripta ne može dohvatiti, jer se implementacije razlikuju i odluka o proxyju nije prekidač za cijeli uređaj. Neki se vraćaju na izravnu vezu, a drugi odbijaju sve, i ta razlika mijenja izgleda li prekid kao pokvaren proxy ili kao ispravna pravila. Potvrdite ponašanje za točan klijent i verziju prije nego se na njega oslonite tijekom incidenta.