Mac VPN ir PAC tarpinis serveris: du sprendimai, o ne vienas nustatymas

Jūsų Mac atsisiunčia politikos scenarijų ir tada klausia to scenarijaus, kokį tarpininką turėtų naudoti užklausa, o tunelis nusprendžia tik tai, kaip pasiekiamas pasirinktas šuolis. Abu atsakymai atsiduria tame pačiame lizde, tad užklausa, kuri nepavyksta po to, kai abu pavyko, atrodo kaip vienas gedimas, nors jų yra dvi. Atsisiuntimo atskyrimas nuo pasirinkimo, o pasirinkimo nuo maršruto, yra didžioji šių bilietų darbo dalis. Toliau pateikta tvarka atkartoja tai, ką macOS iš tikrųjų daro, su patikromis, kurios padaro kiekvieną etapą matomą.

Kur PAC adresas ir tarpinis serveris išsiskiria

Adresas, pavyzdžiui, https://config.corp.example/proxy.pac, įvardija dokumentą, kurį reikia atsisiųsti, o tas dokumentas įvardija serverį, per kurį siunčiamas srautas. URL įklijavimas į tarpinio serverio pagrindinio kompiuterio lauką prašo kliento atidaryti tarpinio serverio ryšį su failų serveriu, kuris niekada neklauso tokio ryšio. Failo viduje yra funkcija, kurią klientas iškviečia kiekvienai užklausai, o jos grąžinama reikšmė yra kitas šuolis tam vienam tikslui. Šis netiesiogumas paaiškina, kodėl du kompiuteriai toje pačioje tinklo paslaugoje gali elgtis skirtingai, nors abu turi teisingą URL. Jis taip pat paaiškina, kodėl politikos pakeitimas įsigalioja niekam neliečiant paties tarpinio serverio.

Perskaitykite scenarijų prieš ką nors interpretuodami toliau, nes jame esančios taisyklės neša organizacijos išimtis ir jų taikymo tvarką. Ankstyvas platus diapazonas gali užgožti vėlesnį vidinį sufiksą, o priegloba, kuri akivaizdžiai turėtų apeiti tarpinį serverį, toliau jį naudoja. Kai kas nors tvirtina, kad politika neteisinga, scenarijus yra vienintelė vieta, kur tas teiginys išsprendžiamas.

Scenarijus turi būti gautas, prieš jam ką nors nusprendžiant

Norint atsisiųsti politiką, reikia išspręsto vardo ir maršruto iki to, kas aptarnauja failą, o prijungtas tunelis negarantuoja nė vieno. Jei priegloba sprendžiama tik per privatų DNS, tuo metu naudojamas sprendėjas nusprendžia, ar atsisiuntimas gali prasidėti. Jei priegloba yra privačiame diapazone, maršrutas turi egzistuoti iš šio kompiuterio, o ne iš kolegos nešiojamojo. Ankstesnėje sesijoje podėlyje išsaugota kopija visa tai paslepia, kol podėlis pasibaigia arba kompiuteris paleidžiamas iš naujo.

Atlikite tris patikras žemiau iš eilės ir sustokite ties pirmąja nesėkme, nes etapai neturi bendros priežasties. Kartu jos parodo, ar politika sukonfigūruota, ar ji pasiekiama ir ką ji grąžina.

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

Pirmoji komanda išspausdina aktyvios paslaugos tarpinių serverių žodyną, įskaitant bet kurį automatinio konfigūravimo URL, kurį laiko sistema. Antroji praneša URL, susietą su viena įvardyta paslauga, o tai svarbu nešiojamajame, kuris juda tarp Wi-Fi ir Ethernet. Trečioji gauna failą jo neatvaizduodama, tad 404, skirtasis laikas ir sprendėjo gedimas lieka atskiriami. Jei ta paskutinė komanda grąžina scenarijų, o programos vis dar nepavyksta, problema jau praėjo gavimo etapą.

Ką DIRECT atsakymas iš tikrųjų praleidžia

PAC specifikacija suteikia klientui mažą žodyną, ir DIRECT yra vienas jo žodžių. Tas žodis liepia klientui praleisti tarpinį serverį tai užklausai ir nieko nesako apie tai, kurią sąsają lizdas tada naudos. Tiesioginis lizdas pilname tunelyje vis tiek išeina per VPN ir vis tiek rodo paskirčiai tunelio išėjimo adresą.

Skaityti DIRECT kaip esantį už VPN ribų yra klaida, kuri nukreipia žmones į netinkamą nustatymų skydelį. Veidrodinis vaizdas taip pat įprastas, nes privatų tarpinį serverį galima pasiekti padalytu maršrutu, kol likusi kompiuterio dalis lieka už tunelio. Tai, ką tada praneša paskirtis, priklauso paties tarpinio serverio išėjimui, kuris gali būti kitoje šalyje. Lūkesčio užrašymas vienai vidinei prieglobai ir vienai viešai prieglobai tai greitai atskleidžia, nes scenarijus dažnai atsako šiems dviem skirtingai. Kai žinote, kuris šuolis sukūrė adresą, ataskaita nustoja būti paslaptinga.

Trys gedimai, kurie pasirodo kaip vienas klaidų puslapis

Politika gali nepavykti atsisiųsti, pasirinktas tarpinis serveris gali būti nepasiekiamas, o užklausa, kuri pasiekia paslaugą, ten vis tiek gali būti atmesta. Visi trys ateina kaip skirtasis laikas arba bendras klaidų puslapis, ir nė vienas neįvardija etapo, kuris lūžo. Sprendimo užfiksavimas šalia klaidos yra tai, kas juos atskiria. Dvi žemiau esančios patikros tikrina šuolį, kurį pasirinko scenarijus, po vieną kiekvienai šakai, kurią jis gali grąžinti.

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

Užbaigtas ryšys su tarpiniu serveriu perkelia klausimą į autentifikavimą arba į paties tarpinio serverio politiką, kuri turi kitą savininką. Užbaigtas ryšys su vidine priegloba be tarpinio serverio kelyje atmeta maršrutą ir nurodo į politiką. Abi komandos ignoruoja macOS tarpinių serverių žodyną, nebent apvalkalas eksportuoja tarpinio serverio kintamuosius, tad pirmiausia juos išvalykite. Nė viena patikra neįrodo kitos, ir todėl vienas klaidų puslapis klaidina taip ilgai.

Ką perduoti kartu su bilietu

Siųskite aktyvią tinklo paslaugą, PAC URL, nesėkmingos prieglobos vertinimo rezultatą ir etapą, kuriame pasirodė klaida. Šie keturi leidžia kitam žmogui atkurti sprendimą, o ne spėlioti, kuris sluoksnis buvo susijęs. Pridėkite tunelio būseną testo metu, nes rezultatas, užfiksuotas prieš pakartotinį prisijungimą, yra pasenęs. Taip pat pasilikite scenarijaus versiją, nes politikos failas keičiasi be įspėjimo, o vakarykštis atsakymas gali nebegalioti.

Užrašykite, kaip klientas elgiasi, kai scenarijaus neįmanoma gauti, nes įgyvendinimai skiriasi, o tarpinio serverio sprendimas nėra viso įrenginio avarinis jungiklis. Kai kurie grįžta prie tiesioginio ryšio, kiti nepavyksta uždarai, ir šis skirtumas keičia, ar triktis atrodo kaip sugedęs tarpinis serveris, ar kaip veikianti politika. Patvirtinkite elgseną tiksliai klientui ir versijai, prieš pasikliaudami ja incidento metu.