VPN pe Mac și proxy PAC: două decizii, nu o singură setare

Mac-ul tău descarcă un script de politică și apoi întreabă acel script ce intermediar ar trebui să folosească o cerere, în timp ce tunelul decide doar cum se ajunge la saltul ales. Ambele răspunsuri ajung pe același socket, așa că o cerere care eșuează după ce ambele au reușit pare o singură defecțiune când sunt două. Separarea descărcării de selecție și a selecției de rută este cea mai mare parte a muncii în aceste tichete. Ordinea de mai jos urmează ce face macOS de fapt, cu verificările care fac fiecare etapă vizibilă.

Unde adresa PAC și proxy-ul diverg

O adresă precum https://config.corp.example/proxy.pac numește un document de descărcat, iar acel document numește un server prin care să treacă traficul. Lipirea URL-ului într-un câmp de gazdă al proxy-ului cere clientului să deschidă o conexiune proxy către un server de fișiere care nu ascultă niciodată una. În fișier există o funcție pe care clientul o apelează la fiecare cerere, iar valoarea returnată este următorul salt pentru acea singură destinație. Această indirecție explică de ce două mașini din același serviciu de rețea se pot comporta diferit deși ambele au URL-ul corect. Explică și de ce o schimbare de politică intră în vigoare fără ca cineva să atingă proxy-ul în sine.

Citiți scriptul înainte de a interpreta orice în aval, pentru că regulile din el poartă excepțiile organizației și ordinea în care se aplică. Un interval larg timpuriu poate umbri un sufix intern ulterior, iar o gazdă care ar trebui evident să ocolească proxy-ul continuă să îl folosească. Când cineva insistă că politica este greșită, scriptul este singurul loc unde acea afirmație se rezolvă.

Scriptul trebuie obținut înainte de a decide ceva

Descărcarea politicii necesită un nume rezolvat și o rută către ce servește fișierul, iar un tunel conectat nu implică niciuna. Dacă gazda se rezolvă doar prin DNS privat, resolverul folosit în acel moment decide dacă descărcarea poate începe. Dacă gazda se află într-un interval privat, ruta trebuie să existe de pe această mașină, nu de pe laptopul unui coleg. O copie din cache dintr-o sesiune anterioară ascunde toate acestea până când cache-ul expiră sau mașina repornește.

Rulați cele trei verificări de mai jos în ordine și opriți-vă la prima eșec, pentru că etapele nu împart o cauză. Împreună arată dacă politica este configurată, dacă este accesibilă și ce returnează.

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

Prima comandă tipărește dicționarul de proxy pentru serviciul activ, inclusiv orice URL de configurare automată pe care sistemul îl deține. A doua raportează URL-ul atașat unui serviciu numit, ceea ce contează pe un laptop care se mută între Wi-Fi și Ethernet. A treia obține fișierul fără a-l randare, astfel încât un 404, un timeout și o eroare de resolver rămân distinse. Dacă ultima comandă returnează scriptul în timp ce aplicațiile încă eșuează, problema a depășit deja obținerea.

Ce omite de fapt un răspuns DIRECT

Specificația PAC oferă clientului un vocabular mic, iar DIRECT este unul dintre cuvintele sale. Cuvântul îi spune clientului să omită proxy-ul pentru acea cerere și nu spune nimic despre ce interfață va folosi socketul după aceea. Un socket direct pe un tunel complet iese totuși prin VPN și arată totuși destinației adresa de ieșire a tunelului.

Citirea DIRECT ca fiind în afara VPN este greșeala care trimite oamenii la panoul de setări greșit. Imaginea în oglindă este la fel de comună, pentru că se poate ajunge la un proxy privat printr-o rută divizată în timp ce restul mașinii rămâne în afara tunelului. Ce raportează atunci destinația aparține ieșirii proxy-ului însuși, care poate fi în altă țară. Scrierea așteptării pentru o gazdă internă și una publică expune repede acest lucru, deoarece scriptul răspunde adesea diferit celor două. Odată ce știți ce salt a produs adresa, raportul încetează să mai fie misterios.

Trei eșecuri care apar ca o singură pagină de eroare

Politica poate eșua la descărcare, proxy-ul ales poate fi inaccesibil, iar o cerere care ajunge la serviciu poate fi totuși refuzată acolo. Toate trei sosesc ca timeout sau pagină de eroare generică, și niciuna nu numește etapa care s-a rupt. Capturarea deciziei lângă eroare este ce le separă. Cele două sonde de mai jos testează saltul pe care scriptul l-a ales, câte una pentru fiecare ramură pe care o poate returna.

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

O conexiune finalizată la proxy mută întrebarea către autentificare sau către propria politică a proxy-ului, care are alt proprietar. O conexiune finalizată la gazda internă fără proxy pe cale exclude ruta și indică politica. Ambele comenzi ignoră dicționarul de proxy al macOS dacă shell-ul nu exportă variabile de proxy, așa că goliți-le mai întâi. Niciuna dintre sonde nu o dovedește pe cealaltă, și de aceea o pagină de eroare induce în eroare atât de mult.

Ce să predai împreună cu tichetul

Trimiteți serviciul de rețea activ, URL-ul PAC, rezultatul evaluării pentru gazda care eșuează și etapa în care a apărut eroarea. Aceste patru îi permit următoarei persoane să reproducă decizia în loc să ghicească ce strat a fost implicat. Adăugați starea tunelului în momentul testului, pentru că un rezultat capturat înainte de o reconectare este învechit. Păstrați și revizia scriptului, deoarece fișierul de politică se schimbă fără anunț, iar răspunsul de ieri poate să nu mai fie valabil.

Notați cum se comportă clientul când scriptul nu poate fi obținut, pentru că implementările diferă, iar decizia proxy nu este un întrerupător general al dispozitivului. Unele revin la o conexiune directă, iar altele eșuează închis, iar această diferență schimbă dacă o pană arată ca un proxy stricat sau ca o politică funcțională. Confirmați comportamentul pentru clientul și versiunea exacte înainte de a vă baza pe el în timpul unui incident.