Mac VPN és PAC proxy: két döntés, nem egyetlen beállítás
A PAC-fájl kérésenként választ proxyt, míg a VPN útvonalat választ. Kövesse a letöltést, a kiválasztást és a socketet, és ne olvassa tovább a DIRECT-et offline állapotként.
A Mac letölt egy házirend-szkriptet, majd megkérdezi a szkriptet, melyik közvetítőt használja egy kérés, miközben az alagút csak azt dönti el, hogyan érhető el a kiválasztott ugrás. Mindkét válasz ugyanazon a socketen landol, ezért az a kérés, amely mindkettő sikeressége után elbukik, egy hibának látszik, holott kettő. A letöltés elválasztása a kiválasztástól, és a kiválasztásé az útvonaltól, ezeknek a ticketeknek a nagy része. Az alábbi sorrend azt követi, amit a macOS valójában tesz, azokkal az ellenőrzésekkel, amelyek minden szakaszt láthatóvá tesznek.
Ahol a PAC-cím és a proxy szétválik
Egy https://config.corp.example/proxy.pac típusú cím megnevez egy letöltendő dokumentumot, és ez a dokumentum megnevez egy szervert, amelyen a forgalom átmegy. Az URL beillesztése egy proxy hosztmezőbe arra kéri a klienst, hogy proxykapcsolatot nyisson egy olyan fájlszerverhez, amely soha nem figyel ilyenre. A fájlon belül van egy függvény, amelyet a kliens minden kérésnél meghív, és a visszatérési értéke a következő ugrás ehhez az egyetlen célponthoz. Ez a közvetettség magyarázza, miért viselkedhet két gép ugyanazon a hálózati szolgáltatáson eltérően, miközben mindkettő a helyes URL-t tartja. Azt is megmagyarázza, miért lép életbe egy házirend-változás anélkül, hogy bárki hozzányúlna magához a proxyhoz.
Olvassa el a szkriptet, mielőtt bármit értelmezne a folyamatban lejjebb, mert a benne lévő szabályok hordozzák a szervezet kivételeit és azok alkalmazási sorrendjét. Egy korai széles tartomány elfedhet egy későbbi belső utótagot, és egy hoszt, amelynek nyilvánvalóan meg kellene kerülnie a proxyt, tovább használja. Amikor valaki azt állítja, hogy a házirend rossz, a szkript az egyetlen hely, ahol ez az állítás eldől.
A szkriptet be kell szerezni, mielőtt bármit eldönt
A házirend letöltéséhez feloldott név és útvonal kell ahhoz, ami a fájlt kiszolgálja, és egy csatlakoztatott alagút egyiket sem jelenti. Ha a hoszt csak privát DNS-en keresztül oldódik fel, az abban a pillanatban használt feloldó dönti el, hogy a letöltés elkezdődhet-e. Ha a hoszt privát tartományban van, az útvonalnak erről a gépéről kell léteznie, nem egy kolléga laptopjáról. Egy korábbi munkamenetben gyorsítótárazott másolat mindezt elrejti, amíg a gyorsítótár le nem jár, vagy a gép újra nem indul.
Futtassa az alábbi három ellenőrzést sorrendben, és álljon meg az első hibánál, mert a szakaszoknak nincs közös okuk. Együtt megmutatják, hogy a házirend be van-e állítva, elérhető-e, és mit ad vissza.
scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac
Az első parancs kiírja az aktív szolgáltatás proxy szótárát, beleértve minden automatikus konfigurációs URL-t, amelyet a rendszer tart. A második az egyik megnevezett szolgáltatáshoz kapcsolt URL-t jelenti, ami számít egy laptopon, amely Wi-Fi és Ethernet között mozog. A harmadik letölti a fájlt anélkül, hogy megjelenítené, így a 404, az időtúllépés és a feloldó hibája megkülönböztethető marad. Ha az utolsó parancs visszaadja a szkriptet, miközben az alkalmazások továbbra is hibáznak, a probléma már túljutott a letöltésen.
Mit hagy ki valójában egy DIRECT válasz
A PAC specifikáció kis szókincset ad az ügyfélnek, és a DIRECT annak egyik szava. A szó azt mondja az ügyfélnek, hogy hagyja ki a proxyt arra a kérésre, és semmit sem mond arról, hogy a socket utána melyik interfészt használja. Egy közvetlen socket teljes alagúton továbbra is a VPN-en keresztül lép ki, és továbbra is az alagút kimenő címét mutatja a célnak.
A DIRECT VPN-en kívüliként olvasása az a hiba, amely rossz beállítási panelhez küldi az embereket. A tükörkép ugyanolyan gyakori, mert egy privát proxy megosztott útvonalon érhető el, miközben a gép többi része az alagúton kívül marad. Amit a cél ilyenkor jelent, az a proxy saját kimenetéhez tartozik, amely lehet más országban. Az elvárás leírása egy belső és egy nyilvános hosztra gyorsan felfedi ezt, mivel a szkript gyakran másképp válaszol a kettőnek. Ha tudja, melyik ugrás hozta létre a címet, a jelentés megszűnik rejtélyesnek lenni.
Három hiba, amely egyetlen hibaoldalként jelenik meg
A házirend letöltése meghiúsulhat, a kiválasztott proxy elérhetetlen lehet, és egy kérés, amely eléri a szolgáltatást, ott még mindig elutasítható. Mindhárom időtúllépésként vagy általános hibaoldalként érkezik, és egyik sem nevezi meg a szakaszt, amely elromlott. A döntés rögzítése a hiba mellett az, ami elválasztja őket. Az alábbi két próba azt az ugrást teszteli, amelyet a szkript választott, egyet-egyet minden ágra, amelyet visszaadhat.
curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/
A proxyhoz befejezett kapcsolat átviszi a kérdést a hitelesítésre vagy a proxy saját házirendjére, amelynek más a tulajdonosa. Az belső hoszthoz proxy nélkül befejezett kapcsolat kizárja az útvonalat, és a házirendre mutat. Mindkét parancs figyelmen kívül hagyja a macOS proxy szótárát, hacsak a héj nem exportál proxyváltozókat, ezért először törölje azokat. Egyik próba sem bizonyítja a másikat, ezért vezet félre egy hibaoldal ilyen sokáig.
Mit adjon át a tickettel
Küldje el az aktív hálózati szolgáltatást, a PAC URL-t, a hibázó hoszt értékelési eredményét és azt a szakaszt, ahol a hiba megjelent. Ez a négy lehetővé teszi a következő embernek a döntés reprodukálását ahelyett, hogy kitalálná, melyik réteg volt érintett. Adja hozzá az alagút állapotát a teszt pillanatában, mert az újracsatlakozás előtt rögzített eredmény elavult. Őrizze meg a szkript revízióját is, mert a házirendfájl figyelmeztetés nélkül változik, és a tegnapi válasz már nem biztos, hogy érvényes.
Rögzítse, hogyan viselkedik az ügyfél, amikor a szkript nem szerezhető be, mert a megvalósítások eltérnek, és a proxy döntése nem eszközszintű vészkapcsoló. Egyesek visszaesnek közvetlen kapcsolatra, mások zártan hibáznak, és ez a különbség megváltoztatja, hogy egy kimaradás törött proxynak vagy működő házirendnek látszik-e. Erősítse meg a viselkedést a pontos ügyfélre és verzióra, mielőtt egy incidens során támaszkodna rá.