Kvifor PAC-fila di vel feil nettverksadapter

Den berbare PC-en er på kontoret sitt Wi-Fi, Ethernet-kabelen er tilkopla, og ein VPN-adapter er framleis til stades. PAC-fila di spør myIpAddress() kva nettverk han er på. Det høyrest rimeleg ut heilt til han får ei adresse som høyrer til feil adapter.

Den manglande detaljen er at funksjonen returnerer éi adresse. Han er ikkje ei oversikt over kvart grensesnitt, og han kontaktar ikkje eit nettstad for å oppdage den offentlege IP-en din. Ei privat adresse, eller til og med ein loopback-reserve, fortel deg ikkje kva utgongsadresse ein proxy-førespurnad vil bruke.

Eitt svar for ein maskin med fleire adresser

Val av nettverksgrensesnitt høyrer til PAC-implementasjonen. Gammalt råd om å omorganisere Windows-adapterar kan skildre ein bestemt nettlesar- og operativsystemversjon, men det er ei dårleg universell løysing. Chromium dokumenterer sin eigen valalgoritme og avgrensingar ved fleire nettverk; ein annan klient må ikkje gjere det same valet.

Byrja med å identifisere verdien den råka nettlesaren faktisk oppgav, og samanlikn han deretter med subnettkontrollane i skriptet ditt. Gjer dette separat på Wi-Fi, Ethernet og den godkjende VPN-tilkoplinga. Ei adresse som ser overraskande ut, kan framleis oppfylle reglane til implementasjonen.

La avgjerda avhenge av mindre gissing

Der det er praktisk, vel ein proxy ut frå vertsnamnet til destinasjonen i staden for eit antatt klientgrensesnitt. Viss nettverksregistrering er nødvendig, bruk eit medvite, dokumentert signal som organisasjonen din kontrollerer. DNS-basert registrering har òg feilmodus, så definer kva som skjer når signalet ikkje er tilgjengeleg.

Nokre implementasjonar tilbyr myIpAddressEx(). Sjekk støtta og returformatet før du tek det i bruk; det er ikkje ei direkte erstatning for ein einaste IPv4-streng. Til slutt, verifiser den resulterande førespurnadsruta uavhengig. Å kjenne att kontoret sitt subnett rett og å nå den tiltenkte proxyen er to separate resultat.