Waarom je PAC-bestand de verkeerde netwerkadapter kiest
Een laptop kan meerdere lokale adressen hebben. Een PAC-regel op basis van myIpAddress() kan een andere interface identificeren dan je verwachtte.
De laptop staat op de Wi-Fi van kantoor, de Ethernet-kabel is aangesloten en er is nog steeds een VPN-adapter. Je PAC-bestand vraagt myIpAddress() op welk netwerk hij zit. Dat klinkt redelijk tot hij een adres krijgt dat bij de verkeerde adapter hoort.
Het ontbrekende detail is dat de functie één adres teruggeeft. Het is geen inventaris van elke interface, en hij neemt geen contact op met een website om je openbare IP te ontdekken. Een privéadres, of zelfs een loopback-terugval, vertelt je niet welk uitgangsadres een verzoek via de proxy zal gebruiken.
Eén antwoord voor een machine met meerdere adressen
De keuze van de netwerkinterface hoort bij de PAC-implementatie. Het oude advies om Windows-adapters opnieuw te ordenen kan een bepaalde browser- en besturingssysteemversie beschrijven, maar het is een slechte universele oplossing. Chromium documenteert zijn eigen keuzealgoritme en beperkingen bij meerdere netwerken; een andere client hoeft niet dezelfde keuze te maken.
Begin met het vaststellen van de waarde die de getroffen browser werkelijk heeft geleverd, en vergelijk die dan met de subnetcontroles in je script. Doe dit afzonderlijk op Wi-Fi, Ethernet en de goedgekeurde VPN-verbinding. Een adres dat verrassend lijkt, kan nog steeds aan de regels van de implementatie voldoen.
Laat de beslissing van minder giswerk afhangen
Kies waar mogelijk een proxy op basis van de doelhostnaam in plaats van een veronderstelde clientinterface. Als netwerkdetectie nodig is, gebruik dan een bewust, gedocumenteerd signaal dat je organisatie beheert. Detectie via DNS heeft ook faalmodi, dus definieer wat er gebeurt als dat signaal niet beschikbaar is.
Sommige implementaties bieden myIpAddressEx(). Controleer de ondersteuning en het retourformaat voordat je het overneemt; het is geen directe vervanging voor één IPv4-string. Controleer ten slotte de resulterende verzoekroute onafhankelijk. Het kantoor-subnet correct herkennen en de bedoelde proxy bereiken zijn twee afzonderlijke uitkomsten.