Varför din PAC-fil väljer fel nätverksadapter

Den bärbara datorn är på kontorets Wi-Fi, Ethernet-kabeln är ansluten och en VPN-adapter finns fortfarande. Din PAC-fil frågar myIpAddress() vilket nätverk den är på. Det låter rimligt tills den får en adress som tillhör fel adapter.

Den saknade detaljen är att funktionen returnerar en enda adress. Den är inte en förteckning över varje gränssnitt, och den kontaktar inte en webbplats för att upptäcka din offentliga IP. En privat adress, eller till och med en loopback-reserv, berättar inte vilken utgångsadress en proxybegäran kommer att använda.

Ett svar för en maskin med flera adresser

Valet av nätverksgränssnitt hör till PAC-implementeringen. Gamla råd om att ordna om Windows-adaptrar kan beskriva en viss webbläsar- och operativsystemversion, men det är en dålig universell lösning. Chromium dokumenterar sin egen urvalsalgoritm och begränsningar vid flera nätverk; en annan klient behöver inte göra samma val.

Börja med att identifiera det värde som den berörda webbläsaren faktiskt angav och jämför det sedan med subnätskontrollerna i ditt skript. Gör detta separat på Wi-Fi, Ethernet och den godkända VPN-anslutningen. En adress som verkar överraskande kan fortfarande uppfylla implementeringens regler.

Låt beslutet bero på mindre gissning

Där det är praktiskt, välj en proxy utifrån målets värdnamn i stället för ett antaget klientgränssnitt. Om nätverksidentifiering behövs, använd en avsiktlig, dokumenterad signal som din organisation kontrollerar. DNS-baserad identifiering har också fellägen, så definiera vad som händer när den signalen inte är tillgänglig.

Vissa implementeringar erbjuder myIpAddressEx(). Kontrollera stödet och returformatet innan du antar det; det är inte en direkt ersättning för en enda IPv4-sträng. Verifiera slutligen den resulterande begäransvägen oberoende. Att korrekt känna igen kontorets subnät och att nå den avsedda proxyn är två separata resultat.