Hoekom jou PAC-lêer die verkeerde netwerkadapter kies

Die skootrekenaar is op kantoor-Wi-Fi, die Ethernet-kabel is ingeprop, en 'n VPN-adapter is steeds teenwoordig. Jou PAC-lêer vra myIpAddress() aan watter netwerk dit is. Dit klink redelik totdat dit 'n adres kry wat aan die verkeerde adapter behoort.

Die ontbrekende detail is dat die funksie een adres teruggee. Dit is nie 'n inventaris van elke koppelvlak nie, en dit kontak nie 'n webwerf om jou publieke IP te ontdek nie. 'n Privaat adres, of selfs 'n loopback-terugval, sê nie vir jou watter uitgangsadres 'n versoek via die proxy sal gebruik nie.

Een antwoord vir 'n masjien met verskeie adresse

Netwerkkoppelvlak-keuse hoort by die PAC-implementering. Ouer advies om Windows-adapters te herorden, beskryf miskien 'n spesifieke blaaier en bedryfstelselweergawe, maar dit is 'n swak algemene oplossing. Chromium dokumenteer sy eie keuse-algoritme en beperkinge vir multihomed hosts; 'n ander kliënt hoef nie dieselfde keuse te maak nie.

Begin deur die waarde te identifiseer wat die betrokke blaaier werklik voorsien het, en vergelyk dit dan met die subnetkontroles in jou script. Doen dit afsonderlik op Wi-Fi, Ethernet en die goedgekeurde VPN-verbinding. 'n Adres wat verrassend lyk, kan steeds aan die implementering se reëls voldoen.

Maak die besluit afhanklik van minder raaiwerk

Waar prakties, kies 'n proxy op grond van die bestemming se gasheernaam eerder as van 'n veronderstelde kliëntkoppelvlak. As netwerkopsporing nodig is, gebruik 'n doelbewuste, gedokumenteerde sein wat jou organisasie beheer. DNS-gebaseerde opsporing het ook foutmodusse, so definieer wat gebeur wanneer daardie sein onbeskikbaar is.

Sommige implementerings bied myIpAddressEx(). Kontroleer die ondersteuning en teruggaweformaat daarvan voordat jy dit aanneem; dit is nie 'n direkte vervanging vir 'n enkele IPv4-string nie. Verifieer laastens die resulterende versoekroete onafhanklik. Om die kantoor-subnet korrek te herken en die bedoelde proxy te bereik, is twee afsonderlike uitkomste.