VPN na Macu i proxy PAC: dwie decyzje, nie jedno ustawienie

Twój Mac pobiera skrypt polityki, a następnie pyta ten skrypt, którego pośrednika powinno użyć żądanie, podczas gdy tunel decyduje tylko, jak osiągany jest wybrany skok. Obie odpowiedzi trafiają do tego samego gniazda, więc żądanie, które zawodzi po tym, jak oba się powiodły, wygląda jak jedna awaria, choć są dwie. Oddzielenie pobierania od wyboru i wyboru od trasy to większość pracy w tych zgłoszeniach. Poniższa kolejność odtwarza to, co macOS naprawdę robi, wraz z kontrolami, które czynią każdy etap widocznym.

Gdzie adres PAC i proxy się rozchodzą

Adres taki jak https://config.corp.example/proxy.pac nazywa dokument do pobrania, a ten dokument nazywa serwer, przez który ma przechodzić ruch. Wklejenie adresu URL w pole hosta proxy prosi klienta o otwarcie połączenia proxy z serwerem plików, który nigdy nie nasłuchuje takiego połączenia. Wewnątrz pliku jest funkcja, którą klient wywołuje przy każdym żądaniu, a jej wartość zwracana to następny skok dla tego jednego celu. Ta pośredniość wyjaśnia, dlaczego dwie maszyny w tej samej usłudze sieciowej mogą zachowywać się różnie, mimo że obie mają prawidłowy adres URL. Wyjaśnia też, dlaczego zmiana polityki wchodzi w życie, choć nikt nie dotyka samego proxy.

Przeczytaj skrypt, zanim cokolwiek zinterpretujesz poniżej, ponieważ zawarte w nim reguły niosą wyjątki organizacji i kolejność ich stosowania. Wczesny szeroki zakres może zasłonić późniejszy sufiks wewnętrzny, a host, który oczywiście powinien omijać proxy, nadal go używa. Gdy ktoś twierdzi, że polityka jest błędna, skrypt jest jedynym miejscem, w którym to twierdzenie się rozstrzyga.

Skrypt musi zostać pobrany, zanim cokolwiek postanowi

Pobranie polityki wymaga rozwiązanej nazwy i trasy do tego, co serwuje plik, a połączony tunel nie gwarantuje żadnego z nich. Jeśli host jest rozwiązywany tylko przez prywatny DNS, używany wtedy resolver decyduje, czy pobieranie może się rozpocząć. Jeśli host znajduje się w zakresie prywatnym, trasa musi istnieć z tej maszyny, a nie z laptopa kolegi. Kopia z pamięci podręcznej z wcześniejszej sesji ukrywa to wszystko, dopóki pamięć nie wygaśnie lub maszyna nie uruchomi się ponownie.

Wykonaj trzy kontrole poniżej w podanej kolejności i zatrzymaj się na pierwszym niepowodzeniu, ponieważ etapy nie mają wspólnej przyczyny. Razem pokazują, czy polityka jest skonfigurowana, czy jest osiągalna i co zwraca.

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

Pierwsze polecenie wypisuje słownik proxy dla aktywnej usługi, w tym każdy adres URL automatycznej konfiguracji, który trzyma system. Drugie zgłasza adres URL przypisany do jednej nazwanej usługi, co ma znaczenie na laptopie przełączającym się między Wi-Fi a Ethernetem. Trzecie pobiera plik bez renderowania, więc 404, przekroczenie czasu i błąd resolvera pozostają rozróżnialne. Jeśli to ostatnie polecenie zwraca skrypt, a aplikacje nadal zawodzą, problem minął już etap pobierania.

Co odpowiedź DIRECT naprawdę pomija

Specyfikacja PAC daje klientowi mały słownik, a DIRECT jest jednym z jego słów. To słowo mówi klientowi, aby pominął proxy dla tego żądania, i nie mówi nic o tym, którego interfejsu gniazdo użyje później. Bezpośrednie gniazdo na pełnym tunelu nadal wychodzi przez VPN i nadal pokazuje celowi adres wyjścia tunelu.

Czytanie DIRECT jako czegoś poza VPN to błąd, który wysyła ludzi do niewłaściwego panelu ustawień. Odbicie lustrzane jest równie częste, ponieważ do prywatnego proxy można dotrzeć przez trasę dzieloną, podczas gdy reszta maszyny pozostaje poza tunelem. To, co cel wtedy zgłasza, należy do własnego wyjścia proxy, które może znajdować się w innym kraju. Zapisanie oczekiwania dla jednego hosta wewnętrznego i jednego publicznego szybko to ujawnia, ponieważ skrypt często odpowiada im różnie. Gdy wiesz, który skok wytworzył adres, raport przestaje być tajemniczy.

Trzy awarie, które objawiają się jako jedna strona błędu

Polityka może się nie pobrać, wybrane proxy może być nieosiągalne, a żądanie, które dotrze do usługi, nadal może zostać tam odrzucone. Wszystkie trzy przychodzą jako przekroczenie czasu lub ogólna strona błędu i żadne nie nazywa etapu, który się zepsuł. Zarejestrowanie decyzji obok błędu jest tym, co je rozdziela. Dwie sondy poniżej testują skok wybrany przez skrypt, po jednej dla każdej gałęzi, którą może zwrócić.

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

Ukończone połączenie z proxy przenosi pytanie do uwierzytelniania lub do własnej polityki proxy, która ma innego właściciela. Ukończone połączenie z hostem wewnętrznym bez proxy na ścieżce wyklucza trasę i wskazuje na politykę. Oba polecenia ignorują słownik proxy macOS, chyba że powłoka eksportuje zmienne proxy, więc najpierw je wyczyść. Żadna sonda nie dowodzi drugiej, i dlatego jedna strona błędu tak długo wprowadza w błąd.

Co przekazać wraz ze zgłoszeniem

Wyślij aktywną usługę sieciową, adres URL PAC, wynik oceny dla zawodzącego hosta i etap, na którym pojawił się błąd. Te cztery pozwalają następnej osobie odtworzyć decyzję zamiast zgadywać, która warstwa była zaangażowana. Dodaj stan tunelu w chwili testu, ponieważ wynik uchwycony przed ponownym połączeniem jest nieaktualny. Zachowaj też wersję skryptu, ponieważ plik polityki zmienia się bez ostrzeżenia, a wczorajsza odpowiedź może już nie być aktualna.

Zanotuj, jak zachowuje się klient, gdy skryptu nie można pobrać, ponieważ implementacje się różnią, a decyzja o proxy nie jest wyłącznikiem awaryjnym całego urządzenia. Niektóre wracają do połączenia bezpośredniego, a inne zawodzą zamknięte, i ta różnica zmienia, czy awaria wygląda jak zepsute proxy, czy jak działająca polityka. Potwierdź zachowanie dla dokładnego klienta i wersji, zanim oprzesz się na nim podczas incydentu.