Mac-VPN en PAC-proxy: twa beslissingen, net ien ynstelling

Jo Mac downloadt in beliedsskript en freget dat skript dan hokker tuskenpartij in fersyk brûke moat, wylst de tunnel allinnich beslút hoe't de keazen hop berikt wurdt. Beide antwurden lânje op deselde socket, dus in fersyk dat misbeteart neidat beide slagge binne, liket op ien flater wylst it twa binne. It skieden fan it downloaden fan de seleksje, en de seleksje fan de rûte, is it grutste part fan it wurk yn dizze tickets. De folchoarder hjirûnder folget wat macOS echt docht, mei de kontrôles dy't elke faze sichtber meitsje.

Wêr't it PAC-adres en de proxy útinoar geane

In adres lykas https://config.corp.example/proxy.pac neamt in dokumint om te downloaden, en dat dokumint neamt in tsjinner om ferkear troch te stjoeren. It plakken fan de URL yn in proxy-hostfjild freget de klant om in proxyferbining te iepenjen nei in bestânstsjerder dat nea op sa'n ferbining harket. Yn it bestân sit in funksje dy't de klant per fersyk oanropt, en de weromjefte is de folgjende hop foar dat iene doel. Dy yndireksje ferklearret wêrom't twa masines op deselde nettsjinst ferskillend gedrage kinne wylst beide de juste URL hawwe. It ferklearret ek wêrom't in beliedswiziging yn gong komt sûnder dat immen de proxy sels oanrekket.

Lês it skript foardat jo wat dan ek streamôf ynterpretearje, want de regels derin drage de útsûnderings fan de organisaasje en de folchoarder wêryn't se jilde. In betiid breed berik kin in lettere ynterne efterheaksel oerskade, en in host dy't fanselssprekkend de proxy omsile moat, bliuwt it brûken. As immen derop stiet dat it belied ferkeard is, is it skript it iennige plak dêr't dy bewearing besljochte wurdt.

It skript moat helle wurde foardat it wat dan ek beslút

It downloaden fan it belied freget in oplost namme en in rûte nei wat it bestân dan ek tsjinnet, en in ferbûne tunnel ymplisearret gjin fan beide. As de host allinnich fia privee DNS oplost wurdt, beslút de resolver dy't op dat stuit brûkt wurdt oft it downloaden begjinne kin. As de host op in privee berik sit, moat de rûte fan dizze masine ôf bestean, net fan de laptop fan in kollega. In kopy dy't by in eardere sesje yn 'e cache stiet, ferberget dit allegear oant de cache ferrint of de masine op 'e nij start.

Fier de trije kontrôles hjirûnder yn folchoarder út en stop by de earste flater, want de fazen diele gjin oarsaak. Tegearre litte se sjen oft it belied konfigurearre is, oft it berikber is en wat it weromjout.

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

It earste kommando prints it proxywurdboek foar de aktive tsjinst, ynklusyf elke autokonfiguraasje-URL dy't it systeem hâldt. It twadde rapportearret de URL dy't oan ien neamde tsjinst ferbûn is, wat fan belang is op in laptop dy't tusken Wi-Fi en Ethernet beweecht. It tredde hellet it bestân sûnder it te rendern, sadat in 404, in time-out en in resolverflater ûnderskiedber bliuwe. As dat lêste kommando it skript weromjout wylst applikaasjes noch misbeteare, is it probleem al foarby it heljen.

Wat in DIRECT-antwurd eins oerslacht

De PAC-spesifikaasje jout de klant in lyts wurdskat, en DIRECT is ien wurd dêrfan. It wurd seit de klant om de proxy foar dat fersyk oer te slaan en seit neat oer hokker ynterface de socket dan brûkt. In direkte socket op in folsleine tunnel giet noch altyd troch de VPN en toant it doel noch altyd it útgongsadres fan de tunnel.

It lêzen fan DIRECT as bûten de VPN is de flater dy't minsken nei it ferkearde ynstellingspaniel stjoert. It spegelbyld is like gewoan, want in privee proxy is berikber oer in splitste rûte wylst de rest fan de masine bûten de tunnel bliuwt. Wat it doel dan rapportearret, heart by de eigen útgong fan de proxy, dy't yn in oar lân lizze kin. It skriuwen fan de ferwachting foar ien ynterne host en ien iepenbiere host lit dit fluch blike, want it skript antwurdet de twa faak ferskillend. Sadree't jo witte hokker hop it adres produsearre hat, hâldt it rapport op mysterieus te wêzen.

Trije flaters dy't as ien flaterpagina oan it ljocht komme

It belied kin misbeteare by it downloaden, de keazen proxy kin ûnberikber wêze, en in fersyk dat by de tsjinst oankomt, kin dêr noch altyd wegere wurde. Alle trije komme as in time-out of in generike flaterpagina, en net ien neamt de faze dy't bruts. It fêstlizzen fan de beslissing njonken de flater is wat se skiedt. De twa probes hjirûnder testen de hop dy't it skript keas, ien foar elke tûke dy't it weromjaan kin.

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

In foltôge ferbining nei de proxy ferpleatst de fraach nei autentikaasje of nei it eigen belied fan de proxy, dat in oare eigner hat. In foltôge ferbining nei de ynterne host sûnder proxy yn it paad slút de rûte út en wiist nei it belied. Beide kommando's negearje it proxywurdboek fan macOS, útsein as de shell proxyfariabelen eksportearret, dus wiskje dy earst. Gjin fan de twa probes bewiist de oare, en dêrom misliedt ien flaterpagina sa lang.

Wat jo mei it ticket oerdrage

Stjoer de aktive nettsjinst, de PAC-URL, it evaluaasjerresultaat foar de misbetearende host en de faze wêr't de flater ferskynde. Dy fjouwer litte de folgjende persoan de beslissing reprodusearje ynstee fan te rieden hokker laach belutsen wie. Foegje de tunnelsteat ta op it momint fan de test, want in resultaat dat foar in werferbining fêstlein is, is ferâldere. Hâld ek de skriptferzje by, want it beliedsbestân feroaret sûnder warskôging en it antwurd fan juster is miskien net mear aktueel.

Registrearje hoe't de klant him gedraacht as it skript net helle wurde kin, want ymplemintaasjes ferskille en de proxybeslissing is gjin apparaatbrede needstop. Guon falle werom op in direkte ferbining en oaren misbeteare sletten, en dat ferskil feroaret oft in steuring as in stikken proxy of as wurkjend belied liket. Befêstigje it gedrach foar de krekte klant en ferzje foardat jo der by in ynsidint op fertrouwe.