Dlaczego proxy PAC w gościnnej maszynie wirtualnej nie działa z adresem URL hosta

„Host używa tego pliku PAC, więc wstawiłem ten sam adres URL do maszyny wirtualnej” to rozsądne zdanie i niepełny plan. Adres PAC wskazuje skrypt zasad, a nie proxy. Dopóki gość nie może pobrać tego skryptu, ocenić go własnymi adresami i następnie dotrzeć do dowolnego proxy, które skrypt nazywa, adres URL jest tylko ciągiem znaków w polu ustawień. Większość zamieszania wokół zasad proxy w maszynach wirtualnych bierze się z traktowania tego jednego wiersza jako całej konfiguracji.

Adres PAC to skrypt, a nie proxy

Plik zawiera funkcję, która przyjmuje adres URL i host, i zwraca opis proxy albo słowo DIRECT. Nic w adresie nie mówi aplikacji, gdzie wysłać ruch; ta decyzja zapada w czasie działania, wewnątrz skryptu, na danych, o które skrypt prosi platformę. Okno ustawień, które przyjmuje adres PAC, przyjmuje wskaźnik do procedury decyzyjnej.

Ta różnica wyjaśnia, dlaczego skopiowanie adresu może wyglądać na udane. Pole zostaje wypełnione, ustawienie zapisane, a błąd pojawia się dopiero później, gdy skryptu nie można pobrać albo gdy zwraca proxy, do którego gość nie dociera.

Cztery kroki zawodzą każdy na swój sposób

Wewnątrz gościa cztery rzeczy muszą się wydarzyć po kolei, a każda ma własny podpis błędu. Gość pobiera plik PAC. Aplikacja ocenia skrypt dla żądanego adresu przy użyciu informacji lokalnych. Wybrane proxy jest rozwiązywane i osiągane. Uwierzytelnianie następuje, jeśli proxy tego wymaga.

Zacznij od udowodnienia pobrania, bo bez niego wszystko dalej jest bez znaczenia. Plik PAC na prywatnym serwerze wymaga dozwolonej ścieżki do tego serwera, zanim pomoże jakakolwiek reguła, a wybór proxy w nieosiągalnym skrypcie nie może stworzyć ścieżki, która by go pobrała:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

Jeśli to żądanie zawodzi z gościa, a działa z hosta, problemem jest ścieżka gościa do serwera PAC, a nie zawartość skryptu. Jeśli zwraca plik JavaScript, przejdź do drugiego kroku i ustal, co skrypt rozstrzyga dla kontekstu gościa.

Ten sam skrypt decyduje inaczej wewnątrz maszyny wirtualnej

Funkcje PAC mogą sprawdzać żądany host i informacje o maszynie wykonującej ocenę. Reguła zbudowana na własnym adresie klienta, na przykład sprawdzająca adres interfejsu albo przynależność do podsieci, zobaczy adres gościa, a nie fizycznego hosta. Za NAT po stronie hosta to różne adresy, więc ten sam skrypt może wybrać inne proxy albo wewnątrz maszyny wirtualnej wrócić do DIRECT.

To nie jest błąd w skrypcie. Skrypt robi dokładnie to, do czego został napisany, z innym wejściem, i to wyjaśnia mylący raport, w którym host używa proxy, a gość łączy się bezpośrednio. Odtwórz decyzję, zamiast rozumować o niej: ewaluator PAC przyjmujący adres i URL, jeśli twoja dystrybucja go zawiera, rozstrzyga sprawę jednym poleceniem. W przeciwnym razie testuj aplikacją, która naprawdę będzie używana, i czytaj jej dziennik proxy, zamiast zgadywać.

Nie wnioskuj, że gość odziedziczył ustawienia proxy hosta ponieważ jego ruch przechodzi przez tłumaczenie po stronie hosta. Tłumaczenie sieci przekazuje pakiety; nie kopiuje konfiguracji aplikacji, a proxy systemowe jest konfiguracją aplikacji.

Narzędzia, które w ogóle nie czytają PAC

Narzędzia wiersza poleceń to osobna granica i właśnie tam traci się dużo czasu. curl nie wykonuje plików PAC, jak jego dokumentacja proxy mówi wprost. Wskazanie zmiennej proxy na adres pobierania PAC nie czyni skryptu punktem końcowym proxy; narzędzie spróbuje mówić HTTP do pliku JavaScript i zawiedzie w sposób, który wygląda jak problem sieciowy.

To samo dotyczy wielu menedżerów pakietów, środowisk uruchomieniowych języków i narzędzi budowania, które respektują tylko jawne zmienne proxy albo własną konfigurację. Jeśli test, na którym ci zależy, to narzędzie CLI, skonfiguruj je z konkretnym proxy, które wybrałby skrypt PAC, i zapisz, jak doszedłeś do tego wyboru, żeby następna osoba mogła to powtórzyć.

W przypadku aplikacji biurkowych w systemie Linux ustawienie systemowe trzeba przełączyć na tryb automatyczny i podać mu adres URL; adres zapisany, gdy tryb jest jeszcze ręczny, nic nie robi. Sprawdź oba, i sprawdź je wewnątrz gościa:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT też jest decyzją

Wynik PAC DIRECT oznacza, że aplikacja omija proxy HTTP, a nie że wydostała się z sieci. Powstałe połączenie nadal może iść trasą systemu operacyjnego przez tunel albo zawieść z powodów, które nie mają nic wspólnego z używaniem proxy. Odwrotnie, wynik proxy opisuje żądanie jednej aplikacji, a nie każdy proces w gościu.

Weryfikuj więc w kierunku, w którym zapisano wymaganie. Jeśli wymaganie brzmi „ta aplikacja dociera do witryny wewnętrznej”, udowodnij, że ta aplikacja dociera, i zanotuj, które proxy albo która trasa ją niosły. Jeśli wymaganie brzmi „maszyna wirtualna jest w sieci firmowej”, przeglądarka działająca przez wybrane proxy jest dowodem dla tej przeglądarki i niczym więcej.

Napraw łańcuch wewnątrz gościa, zamiast wyłączać tunel hosta albo łagodzić zasady przekazywania, żeby test przeszedł. Łańcuch ma cztery ogniwa, a zmiana, która pomija jedno z nich, utrzyma się do następnego razu, gdy skrypt zostanie zaktualizowany albo adres gościa się zmieni.