Mac VPN un PAC starpniekserveris: divi lēmumi, nevis viens iestatījums

Jūsu Mac lejupielādē politikas skriptu un pēc tam jautā šim skriptam, kuru starpnieku pieprasījumam vajadzētu izmantot, kamēr tunelis izlemj tikai to, kā tiek sasniegts izvēlētais lēciens. Abas atbildes nonāk vienā un tajā pašā ligzdā, tāpēc pieprasījums, kas neizdodas pēc tam, kad abi ir izdevušies, izskatās kā viena kļūda, lai gan tās ir divas. Lejupielādes atdalīšana no izvēles un izvēles atdalīšana no maršruta ir lielākā daļa darba šajos pieteikumos. Tālāk dotā secība atkārto to, ko macOS patiešām dara, ar pārbaudēm, kas padara katru posmu redzamu.

Kur PAC adrese un starpniekserveris atšķiras

Adrese, piemēram, https://config.corp.example/proxy.pac, nosauc lejupielādējamu dokumentu, un šis dokuments nosauc serveri, caur kuru sūtīt datplūsmu. URL ielīmēšana starpniekservera resursdatora laukā liek klientam atvērt starpniekservera savienojumu ar failu serveri, kas nekad neklausās šādu savienojumu. Faila iekšienē ir funkcija, kuru klients izsauc katram pieprasījumam, un tās atgrieztā vērtība ir nākamais lēciens šim vienīgajam galamērķim. Šī netiešība izskaidro, kāpēc divas mašīnas vienā tīkla pakalpojumā var uzvesties atšķirīgi, lai gan abām ir pareizais URL. Tā arī izskaidro, kāpēc politikas izmaiņas stājas spēkā, nevienam neaiztiekot pašu starpniekserveri.

Izlasiiet skriptu, pirms kaut ko interpretējat lejupējā plūsmā, jo tajā esošie noteikumi nes organizācijas izņēmumus un to piemērošanas kārtību. Agrīns plašs diapazons var aizēnot vēlāku iekšēju sufiksu, un resursdators, kuram acīmredzami vajadzētu apiet starpniekserveri, turpina to izmantot. Kad kāds uzstāj, ka politika ir nepareiza, skripts ir vienīgā vieta, kur šis apgalvojums tiek izšķirts.

Skripts ir jāiegūst, pirms tas kaut ko izlemj

Politikas lejupielādei nepieciešams atrisināts nosaukums un maršruts uz to, kas apkalpo failu, un pievienots tunelis negarantē ne vienu, ne otru. Ja resursdators tiek atrisināts tikai caur privātu DNS, tajā brīdī izmantotais risinātājs izlemj, vai lejupielāde var sākties. Ja resursdators atrodas privātā diapazonā, maršrutam jāpastāv no šīs mašīnas, nevis no kolēģa portatīvā datora. Iepriekšējā sesijā kešatmiņā saglabāta kopija to visu slēpj, līdz kešatmiņa beidzas vai mašīna tiek restartēta.

Izpildiet trīs pārbaudes zemāk pēc kārtas un apstājieties pie pirmās neveiksmes, jo posmiem nav kopīga cēloņa. Kopā tās parāda, vai politika ir konfigurēta, vai tā ir sasniedzama un ko tā atgriež.

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

Pirmā komanda izdrukā aktīvā pakalpojuma starpniekservera vārdnīcu, tostarp jebkuru automātiskās konfigurācijas URL, ko sistēma tur. Otrā ziņo par URL, kas piesaistīts vienam nosauktam pakalpojumam, un tas ir svarīgi portatīvajā datorā, kas pārvietojas starp Wi-Fi un Ethernet. Trešā iegūst failu, to neatveidojot, tāpēc 404, taimauts un risinātāja kļūme paliek atšķirami. Ja šī pēdējā komanda atgriež skriptu, kamēr lietojumprogrammas joprojām neizdodas, problēma jau ir pārsniegusi iegūšanu.

Ko DIRECT atbilde patiešām izlaiž

PAC specifikācija dod klientam nelielu vārdu krājumu, un DIRECT ir viens no tā vārdiem. Šis vārds liek klientam izlaist starpniekserveri šim pieprasījumam un neko nesaka par to, kuru saskarni ligzda pēc tam izmantos. Tieša ligzda pilnā tunelī joprojām iziet caur VPN un joprojām rāda galamērķim tuneļa izejas adresi.

Lasīt DIRECT kā ārpus VPN ir kļūda, kas cilvēkus aizsūta uz nepareizo iestatījumu paneli. Spoguļattēls ir tikpat izplatīts, jo privātu starpniekserveri var sasniegt pa sadalītu maršrutu, kamēr pārējā mašīna paliek ārpus tuneļa. Tas, ko galamērķis tad ziņo, pieder paša starpniekservera izejai, kas var atrasties citā valstī. Gaidīšanas pierakstīšana vienam iekšējam resursdatoram un vienam publiskam resursdatoram to ātri atklāj, jo skripts bieži abiem atbild atšķirīgi. Kad zināt, kurš lēciens radīja adresi, ziņojums pārstāj būt noslēpumains.

Trīs kļūmes, kas parādās kā viena kļūdu lapa

Politika var neizdoties lejupielādēt, izvēlētais starpniekserveris var būt nesasniedzams, un pieprasījums, kas nonāk pakalpojumā, tur joprojām var tikt noraidīts. Visi trīs nāk kā taimauts vai vispārīga kļūdu lapa, un neviens nenosauc posmu, kas salūza. Lēmuma fiksēšana blakus kļūdai ir tas, kas tos atdala. Divas zemāk esošās pārbaudes testē lēcienu, kuru skripts izvēlējās, pa vienai katrai atzaram, kuru tas var atgriezt.

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

Pabeigts savienojums ar starpniekserveri pārvieto jautājumu uz autentifikāciju vai uz paša starpniekservera politiku, kurai ir cits īpašnieks. Pabeigts savienojums ar iekšējo resursdatoru bez starpniekservera ceļā izslēdz maršrutu un norāda uz politiku. Abas komandas ignorē macOS starpniekservera vārdnīcu, ja vien čaula neeksportē starpniekservera mainīgos, tāpēc vispirms tos notīriet. Neviena pārbaude neapstiprina otru, un tāpēc viena kļūdu lapa maldina tik ilgi.

Ko nodot kopā ar pieteikumu

Nosūtiet aktīvo tīkla pakalpojumu, PAC URL, neveiksmīgā resursdatora novērtējuma rezultātu un posmu, kurā parādījās kļūda. Šie četri ļauj nākamajam cilvēkam atkārtot lēmumu, nevis minēt, kurš slānis bija iesaistīts. Pievienojiet tuneļa stāvokli testa brīdī, jo rezultāts, kas fiksēts pirms atkārtota savienojuma, ir novecojis. Saglabājiet arī skripta versiju, jo politikas fails mainās bez brīdinājuma un vakardienas atbilde var vairs nebūt aktuāla.

Pierakstiet, kā klients uzvedas, kad skriptu nevar iegūt, jo ieviešanas atšķiras un starpniekservera lēmums nav visas ierīces avārijas slēdzis. Daži atgriežas pie tieša savienojuma, citi neizdodas slēgti, un šī atšķirība maina to, vai pārtraukums izskatās kā salauzts starpniekserveris vai kā strādājoša politika. Apstipriniet uzvedību precīzam klientam un versijai, pirms paļaujaties uz to incidenta laikā.