Kial via PAC-dosiero elektas la malĝustan retkartan adaptilon
Tekkomputilo povas havi plurajn lokajn adresojn. PAC-regulo bazita sur myIpAddress() povas identigi alian interfacon ol tiu, kiun vi atendis.
La tekkomputilo estas en la oficeja Wi-Fi, la Ethernet-kablo estas konektita, kaj VPN-adaptilo ankoraŭ ĉeestas. Via PAC-dosiero demandas al myIpAddress() en kiu reto ĝi estas. Tio ŝajnas racia ĝis ĝi ricevas adreson apartenantan al la malĝusta adaptilo.
La mankanta detalo estas ke la funkcio redonas unu adreson. Ĝi ne estas inventaro de ĉiu interfaco, kaj ĝi ne kontaktas retejon por eltrovi vian publikan IP. Privata adreso, aŭ eĉ loopback-rezervo, ne diras al vi kiun eliran adreson uzos peto tra prokurilo.
Unu respondo por maŝino kun pluraj adresoj
La elekto de retinterfaco apartenas al la PAC-realigo. Malnova konsilo reordigi Windows-adaptilojn eble priskribas specifan retumilan kaj operaciuman version, sed ĝi estas malbona universala solvo. Chromium dokumentas sian propran elektan algoritmon kaj limigojn pri pluraj retoj; alia kliento ne devas fari la saman elekton.
Komencu identigante la valoron, kiun la koncernata retumilo efektive liveris, poste komparu ĝin kun la subretaj kontroloj en via skripto. Faru tion aparte en Wi-Fi, Ethernet kaj la aprobita VPN-konekto. Adreso, kiu aspektas surpriza, povas ankoraŭ plenumi la regulojn de la realigo.
Igu la decidon dependi de malpli da konjektado
Kie praktike, elektu prokurilon laŭ la cela gastnomo anstataŭ laŭ supozita klienta interfaco. Se reta identigo necesas, uzu intencan, dokumentitan signalon, kiun via organizo kontrolas. DNS-bazita identigo ankaŭ havas malsukcesajn reĝimojn, do difinu, kio okazas kiam tiu signalo ne haveblas.
Iuj realigoj ofertas myIpAddressEx(). Kontrolu ĝian subtenon kaj redonan formaton antaŭ ol adopti ĝin; ĝi ne estas rekta anstataŭaĵo por unu IPv4-ĉeno. Fine, sendepende kontrolu la rezultan petvojon. Ĝuste rekoni la oficejan subreton kaj atingi la celitan prokurilon estas du apartaj rezultoj.