Mac VPN a PAC proxy: dvě rozhodnutí, ne jedno nastavení
Soubor PAC volí proxy pro každý požadavek, zatímco VPN volí trasu. Sledujte stahování, volbu a socket a přestaňte číst DIRECT jako offline.
Váš Mac stáhne skript zásad a potom se tohoto skriptu ptá, který prostředník má požadavek použít, zatímco tunel rozhoduje jen o tom, jak se dosáhne zvoleného skoku. Obě odpovědi končí na stejném socketu, takže požadavek, který selže poté, co obě uspěly, vypadá jako jedna závada, i když jsou dvě. Oddělení stahování od volby a volby od trasy je většina práce na těchto tikatech. Pořadí níže sleduje, co macOS skutečně dělá, s kontrolami, které každou fázi zviditelní.
Kde se adresa PAC a proxy rozcházejí
Adresa jako https://config.corp.example/proxy.pac pojmenovává dokument ke stažení a tento dokument pojmenovává server, přes který má provoz jít. Vložení URL do pole hostitele proxy žádá klienta, aby otevřel proxy spojení k souborovému serveru, který takové spojení nikdy neposlouchá. Uvnitř souboru je funkce, kterou klient volá pro každý požadavek, a její návratová hodnota je další skok pro tuto jedinou destinaci. Tato nepřímost vysvětluje, proč se dva počítače na stejné síťové službě mohou chovat různě, i když oba mají správnou URL. Vysvětluje také, proč změna zásad vstoupí v platnost, aniž by se někdo dotkl samotného proxy.
Přečtěte si skript dříve, než cokoli dál vyložíte, protože pravidla v něm nesou výjimky organizace a pořadí, v jakém se uplatňují. Raný široký rozsah může zastínit pozdější interní sufix a hostitel, který měl zjevně proxy obejít, ji nadále používá. Když někdo trvá na tom, že zásady jsou špatné, skript je jediné místo, kde se toto tvrzení vyřeší.
Skript se musí stáhnout, než cokoli rozhodne
Stažení zásad vyžaduje přeložené jméno a trasu k tomu, co soubor obsluhuje, a připojený tunel neznamená ani jedno. Pokud se hostitel překládá jen přes privátní DNS, rozhoduje o tom, zda stahování může začít, resolver používaný v tu chvíli. Pokud hostitel leží v privátním rozsahu, trasa musí existovat z tohoto počítače, ne z kolegova notebooku. Kopie uložená v mezipaměti během dřívější relace to vše skrývá, dokud mezipaměť nevyprší nebo se počítač nerestartuje.
Proveďte tři kontroly níže v pořadí a zastavte se u prvního selhání, protože fáze nemají společnou příčinu. Dohromady ukazují, zda jsou zásady nastavené, zda jsou dosažitelné a co vracejí.
scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac
První příkaz vypíše slovníku proxy pro aktivní službu, včetně každé URL automatické konfigurace, kterou systém drží. Druhý hlásí URL připojenou k jedné pojmenované službě, což je důležité na notebooku, který přechází mezi Wi-Fi a Ethernet. Třetí stáhne soubor bez vykreslení, takže 404, vypršení času i selhání resolveru zůstávají rozlišitelné. Pokud poslední příkaz vrátí skript, zatímco aplikace stále selhávají, problém už přešel fázi stahování.
Co odpověď DIRECT skutečně přeskakuje
Specifikace PAC dává klientovi malý slovník a DIRECT je jedno z jeho slov. Slovo říká klientovi, aby pro tento požadavek proxy přeskočil, a neříká nic o tom, které rozhraní socket potom použije. Přímý socket na plném tunelu přesto vychází přes VPN a přesto destinaci ukazuje výstupní adresu tunelu.
Číst DIRECT jako něco mimo VPN je chyba, která lidi posílá do špatného panelu nastavení. Zrcadlový obraz je stejně častý, protože k privátnímu proxy lze dojít po rozdělené trase, zatímco zbytek počítače zůstává mimo tunel. Co pak destinace hlásí, patří vlastnímu výstupu proxy, který může být v jiné zemi. Zapsání očekávání pro jednoho interního a jednoho veřejného hostitele to rychle odhalí, protože skript na oba často odpovídá jinak. Jakmile víte, který skok adresu vytvořil, zpráva přestane být záhadná.
Tři selhání, která se projeví jako jedna chybová stránka
Zásady se nemusí stáhnout, zvolený proxy nemusí být dostupný a požadavek, který dorazí do služby, tam může být stále odmítnut. Všechny tři přicházejí jako vypršení času nebo obecná chybová stránka a žádné nepojmenovává fázi, která se zlomila. Zachycení rozhodnutí vedle chyby je to, co je odděluje. Dvě sondy níže testují skok, který skript zvolil, jednu pro každou větev, kterou může vrátit.
curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/
Dokončené připojení k proxy přesouvá otázku na autentizaci nebo na vlastní zásady proxy, které mají jiného vlastníka. Dokončené připojení k internímu hostiteli bez proxy v cestě vylučuje trasu a ukazuje na zásady. Oba příkazy ignorují slovníku proxy v macOS, pokud shell neexportuje proměnné proxy, takže je nejprve vymažte. Ani jedna sonda nedokazuje druhou, a proto jedna chybová stránka tak dlouho mate.
Co předat spolu s tiketem
Pošlete aktivní síťovou službu, URL PAC, výsledek vyhodnocení pro selhávajícího hostitele a fázi, ve které se chyba objevila. Tyto čtyři údaje umožní dalšímu člověku rozhodnutí zreprodukovat místo hádání, která vrstva byla zapojena. Přidejte stav tunelu v okamžiku testu, protože výsledek zachycený před opětovným připojením je zastaralý. Uchovejte také revizi skriptu, protože soubor zásad se mění bez oznámení a včerejší odpověď už nemusí být aktuální.
Zaznamenejte, jak se klient chová, když skript nelze stáhnout, protože implementace se liší a rozhodnutí o proxy není celozařízení vypínač. Některé se vracejí k přímému připojení a jiné selhávají zavřené, a tento rozdíl mění, zda výpadek vypadá jako rozbitá proxy, nebo jako fungující zásady. Potvrďte chování pro přesného klienta a verzi, než se na něj během incidentu spolehnete.