Dlaczego plik PAC wybiera niewłaściwy adapter sieciowy

Laptop jest w sieci Wi-Fi biura, kabel Ethernet jest podłączony, a adapter VPN nadal istnieje. Plik PAC pyta myIpAddress(), w której sieci się znajduje. Brzmi to rozsądnie, dopóki nie otrzyma adresu należącego do niewłaściwego adaptera.

Brakującym szczegółem jest to, że funkcja zwraca jeden adres. Nie jest to inwentarz wszystkich interfejsów i nie kontaktuje się ze stroną internetową, aby poznać Twoje publiczne IP. Adres prywatny, a nawet zapasowy loopback, nie mówi, którego adresu wyjściowego użyje żądanie przez proxy.

Jedna odpowiedź dla maszyny z kilkoma adresami

Wybór interfejsu sieciowego należy do implementacji PAC. Stara rada, by zmienić kolejność adapterów Windows, może opisywać konkretną wersję przeglądarki i systemu operacyjnego, ale jest złym uniwersalnym rozwiązaniem. Chromium dokumentuje własny algorytm wyboru i ograniczenia sieci wielohostowych; inny klient nie musi dokonywać tego samego wyboru.

Zacznij od ustalenia wartości, którą dana przeglądarka faktycznie podała, a następnie porównaj ją z kontrolami podsieci w skrypcie. Zrób to osobno w Wi-Fi, Ethernet i zatwierdzonym połączeniu VPN. Adres, który wygląda zaskakująco, nadal może spełniać reguły implementacji.

Uzależnij decyzję od mniejszej liczby domysłów

Gdzie to możliwe, wybieraj proxy na podstawie nazwy hosta docelowego, a nie założonego interfejsu klienta. Jeśli wykrywanie sieci jest konieczne, użyj celowego, udokumentowanego sygnału kontrolowanego przez organizację. Wykrywanie oparte na DNS również ma tryby awarii, więc określ, co się dzieje, gdy ten sygnał jest niedostępny.

Niektóre implementacje oferują myIpAddressEx(). Sprawdź obsługę i format zwrotu przed przyjęciem; nie jest to bezpośredni zamiennik pojedynczego ciągu IPv4. Na koniec zweryfikuj wynikową trasę żądania niezależnie. Prawidłowe rozpoznanie podsieci biurowej i dotarcie do zamierzonego proxy to dwa odrębne wyniki.