Mac VPN en PAC-proxy: twee besluite, nie een instelling nie

Jou Mac laai 'n beleidskrip af en vra dan daardie skrip watter tussenparty 'n versoek moet gebruik, terwyl die tonnel net besluit hoe die gekose sprong bereik word. Albei antwoorde beland op dieselfde sokkel, so 'n versoek wat misluk nadat albei geslaag het, lyk soos een fout wanneer dit twee is. Om die aflaai van die keuse te skei, en die keuse van die roete, is die grootste deel van die werk in hierdie kaartjies. Die volgorde hieronder volg wat macOS werklik doen, met die kontroles wat elke stadium sigbaar maak.

Waar die PAC-adres en die proxy uitmekaar loop

'n Adres soos https://config.corp.example/proxy.pac noem 'n dokument om af te laai, en daardie dokument noem 'n bediener om verkeer deur te stuur. Om die URL in 'n proxy-gasheerveld te plak, vra die kliënt om 'n proxy-verbinding te open na 'n lêerbediener wat nooit vir een luister nie. Binne die lêer is 'n funksie wat die kliënt per versoek roep, en die terugwaarde daarvan is die volgende sprong vir daardie enkele bestemming. Daardie indireksie verduidelik waarom twee masjiene op dieselfde netwerkdiens anders kan optree terwyl albei die korrekte URL het. Dit verduidelik ook waarom 'n beleidsverandering in werking tree sonder dat iemand aan die proxy self raak.

Lees die skrip voordat jy enigiets stroomaf interpreteer, want die reëls daarin dra die organisasie se uitsonderings en die orde waarin hulle geld. 'n Vroeë breë reeks kan 'n latere interne agtervoegsel oorskadu, en 'n gasheer wat ooglopend die proxy moet omseil, bly dit gebruik. Wanneer iemand aandring dat die beleid verkeerd is, is die skrip die enigste plek waar daardie bewering besleg word.

Die skrip moet afgelaai word voordat dit enigiets besluit

Om die beleid af te laai, is 'n naam nodig wat opgelos word en 'n roete na wat die lêer ook al bedien, en 'n gekoppelde tonnel impliseer nie een van die twee nie. As die gasheer net deur private DNS opgelos word, besluit die oplosser wat op daardie oomblik gebruik word of die aflaai kan begin. As die gasheer op 'n private reeks sit, moet die roete van hierdie masjien af bestaan, nie van 'n kollega se skootrekenaar nie. 'n Kopie wat tydens 'n vroeëre sessie gekas is, verberg dit alles totdat die kas verval of die masjien herbegin.

Voer die drie kontroles hieronder in volgorde uit en stop by die eerste fout, want die stadiums deel nie 'n oorsaak nie. Saam wys hulle of die beleid opgestel is, of dit bereikbaar is, en wat dit teruggee.

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

Die eerste opdrag druk die proxy-woordeboek vir die aktiewe diens, insluitend enige outo-konfigurasie-URL wat die stelsel hou. Die tweede rapporteer die URL wat aan een genoemde diens gekoppel is, wat saak maak op 'n skootrekenaar wat tussen Wi-Fi en Ethernet beweeg. Die derde haal die lêer sonder om dit te lewer, sodat 'n 404, 'n tydsverloop en 'n oplosserfout onderskeibaar bly. As daardie laaste opdrag die skrip teruggee terwyl programme steeds faal, het die probleem al verby die ophaal beweeg.

Wat 'n DIRECT-antwoord eintlik oorslaan

PAC-spesifikasie gee die kliënt 'n klein woordeskat, en DIRECT is een woord daarvan. Die woord sê vir die kliënt om die proxy vir daardie versoek oor te slaan en sê niks oor watter koppelvlak die sokkel dan gebruik nie. 'n Direkte sokkel op 'n vol tonnel verlaat steeds deur die VPN en wys steeds die tonnel se uitgangsadres aan die bestemming.

Om DIRECT as buite die VPN te lees, is die fout wat mense na die verkeerde instellingspaneel stuur. Die spieëlbeeld is net so algemeen, want 'n private proxy kan oor 'n gesplete roete bereik word terwyl die res van die masjien van die tonnel af bly. Wat die bestemming dan rapporteer, behoort aan die proxy se eie uitgang, wat in 'n ander land kan sit. Om die verwagting vir een interne gasheer en een openbare gasheer te skryf, lê dit vinnig bloot, want die skrip antwoord die twee dikwels verskillend. Sodra jy weet watter sprong die adres opgelewer het, hou die verslag op om raaiselagtig te wees.

Drie foute wat as een foutbladsy opduik

Die beleid kan misluk om af te laai, die gekose proxy kan onbereikbaar wees, en 'n versoek wat by die diens aankom, kan daar steeds geweier word. Al drie kom as 'n tydsverloop of 'n generiese foutbladsy, en nie een noem die stadium wat gebreek het nie. Om die besluit langs die fout vas te vang, is wat hulle skei. Die twee ondersoeke hieronder toets die sprong wat die skrip gekies het, een vir elke tak wat dit kan teruggee.

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

'n Voltooide verbinding na die proxy skuif die vraag na verifikasie of na die proxy se eie beleid, wat 'n ander eienaar het. 'n Voltooide verbinding na die interne gasheer sonder 'n proxy in die pad sluit die roete uit en wys na die beleid. Albei opdragte ignoreer die macOS-proxy-woordeboek tensy die skulp proxy-veranderlikes uitvoer, so maak dié eers skoon. Geen van die ondersoeke bewys die ander nie, en daarom mislei een foutbladsy so lank.

Wat om saam met die kaartjie oor te dra

Stuur die aktiewe netwerkdiens, die PAC-URL, die evaluasie-uitslag vir die gasheer wat faal, en die stadium waar die fout verskyn het. Daardie vier laat die volgende persoon die besluit herproduseer in plaas daarvan om te raai watter laag betrokke was. Voeg die tonneltoestand by op die oomblik van die toets, want 'n uitslag wat voor 'n herverbinding vasgevang is, is verouderd. Hou ook die skripweergawe, want die beleidlêer verander sonder kennisgewing en gister se antwoord is dalk nie meer aktueel nie.

Teken aan hoe die kliënt optree wanneer die skrip nie opgehaal kan word nie, want implementerings verskil en die proxy-besluit is nie 'n toestelwye doodskakelaar nie. Sommige val terug op 'n direkte verbinding en ander faal geslote, en daardie verskil verander of 'n onderbreking soos 'n stukkende proxy of soos werkende beleid lyk. Bevestig die gedrag vir die presiese kliënt en weergawe voordat jy daarop staatmaak tydens 'n voorval.