curl nie czyta twojego pliku PAC: podaj zamiast niego proxy

Adres pliku PAC i punkt końcowy proxy wyglądają w pliku konfiguracyjnym na wymienne, ale takie nie są. Jeden to program polityki, który trzeba ocenić dla każdego URL; drugi to host i port, które przyjmują połączenia. curl rozumie tylko ten drugi. Podanie adresu PAC do --proxy to błąd kategorii, który kończy się niepowodzeniem w mylący sposób, zwykle po długim przekroczeniu czasu CONNECT do serwera WWW.

Czym naprawdę jest każde z nich

Mówi to wprost FAQ dotyczące curl: curl nie zapewnia interpretacji JavaScript ani PAC. Otoczka wokół curl, która rozumie PAC, może to robić, ale sam curl nie, i żadna opcja nie czyni z niego przeglądarki.

Dlaczego przeglądarka działa, a curl nie

Przeglądarka integruje się z konfiguracją proxy systemu, pobiera plik PAC i wykonuje jego reguły wobec URL, który otwierasz. Ta ocena jest usługą, którą daje plik PAC, i odbywa się wewnątrz przeglądarki, a nie w twoim terminalu.

Pobranie pliku PAC za pomocą curl daje tylko jego tekst. Nie sprawia, że curl wykonuje politykę, a ręczne czytanie go w poszukiwaniu proxy jest ręczną wersją tej samej oceny, z taką samą szansą wybrania niewłaściwej gałęzi. Jeśli go czytasz, przeczytaj instrukcję return pasującą do twojego hosta, a nie pierwszą nazwę proxy w pliku. Większość plików PAC zawiera ich kilka, a tylko jedna gałąź dotyczy ciebie.

Dla zatwierdzonego proxy HTTP i zatwierdzonej usługi HTTPS przykładowe żądanie to:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Pierwszy adres to odbiorca proxy, drugi to usługa, której chcesz. To przykładowe punkty końcowe, a nie test, który ktoś przeprowadził, więc zastąp je schematem, portem i procesem uwierzytelniania twojej organizacji.

Wybierz proxy dla tego celu

Zapytaj administratora, które proxy wybiera polityka dla potrzebnego URL, a nie które proxy ma organizacja. Reguły PAC mogą zwracać różne wyniki dla usług wewnętrznych, witryn publicznych i stanów przełączenia awaryjnego, a reguła pasująca dziś do twojego URL po edycji może pasować do innego.

Jeśli przepływ pracy wymaga więcej niż jednego znanego żądania, użyj ustawienia statycznego wspieranego przez administratora albo zatwierdzonej integracji rozumiejącej PAC. Zaszycie na stałe jednego skopiowanego adresu działa do dnia, w którym polityka się zmieni i nikt już nie pamięta, dlaczego wybrano ten adres.

Potem sprawdź, co curl dziedziczy. Zmienne środowiskowe proxy i NO_PROXY mogą nadpisać lub wykluczyć podane proxy, a wykluczenie pasujące do celu wysyła żądanie bezpośrednio bez ostrzeżenia. Zachowaj zamierzoną politykę zamiast usuwać każde wykluczenie albo zmuszać wszystko do przejścia przez jeden adres. Wykonaj żądanie raz z -v i sprawdź, z którym adresem faktycznie się połączył.

Trzymaj dwie tożsamości TLS osobno

Przy proxy HTTPS w grę wchodzą dwa połączenia TLS: twoje do proxy i połączenie proxy do celu. Każde ma własną tożsamość do zweryfikowania, a wyłączenie weryfikacji dla któregokolwiek z nich nie jest poprawką PAC, to drugi problem dodany do pierwszego.

Zostaw weryfikację włączoną i przeczytaj błąd, który otrzymasz. Wyzwanie uwierzytelniania proxy, nieosiągalne proxy i odmowa ze strony witryny to trzy różne wyniki, a tylko pierwszy dotyczy poświadczeń. VPN nadal musi zapewnić dozwoloną ścieżkę do prywatnego proxy, w tym rozwiązywanie nazw dla samego hosta proxy, zanim cokolwiek z tego się uda.

Zapisz punkt końcowy, schemat, port, metodę uwierzytelniania, wykluczenia i ścieżkę VPN do proxy. Ten zapis sprawia, że następne żądanie jest powtarzalne, i to jest różnica między znajomością swojego proxy a zgadywaniem go.