Kāpēc jūsu PAC fails izvēlas nepareizo tīkla adapteri

Klēpjdators ir biroja Wi-Fi tīklā, Ethernet kabelis ir pievienots, un VPN adapteris joprojām ir. Jūsu PAC fails jautā myIpAddress(), kurā tīklā tas atrodas. Tas šķiet saprātīgi, līdz tas saņem adresi, kas pieder nepareizajam adapterim.

Trūkstošā detaļa ir tā, ka funkcija atgriež vienu adresi. Tas nav visu saskarņu uzskaitījums, un tā nesazinās ar vietni, lai atklātu jūsu publisko IP. Privāta adrese vai pat loopback rezerves variants nepasaka, kuru izejas adresi izmantos pieprasījums caur starpniekserveri.

Viena atbilde iekārtai ar vairākām adresēm

Tīkla saskarnes izvēle pieder PAC ieviešanai. Vecais padoms pārkārtot Windows adapterus var aprakstīt konkrētu pārlūka un operētājsistēmas versiju, taču tas ir slikts universāls risinājums. Chromium dokumentē savu izvēles algoritmu un vairāku tīklu ierobežojumus; citam klientam nav jāizdara tāda pati izvēle.

Sāciet ar tās vērtības noteikšanu, ko skartais pārlūks faktiski sniedza, pēc tam salīdziniet to ar apakštīkla pārbaudēm savā skriptā. Dariet to atsevišķi Wi-Fi, Ethernet un apstiprinātajā VPN savienojumā. Adrese, kas izskatās pārsteidzoša, joprojām var atbilst ieviešanas noteikumiem.

Padariet lēmumu mazāk atkarīgu no minējumiem

Kur iespējams, izvēlieties starpniekserveri pēc galamērķa resursdatora nosaukuma, nevis pēc pieņemtas klienta saskarnes. Ja nepieciešama tīkla noteikšana, izmantojiet apzinātu, dokumentētu signālu, ko kontrolē jūsu organizācija. Arī DNS balstītai noteikšanai ir kļūmes režīmi, tāpēc definējiet, kas notiek, ja šis signāls nav pieejams.

Dažas ieviešanas piedāvā myIpAddressEx(). Pirms pieņemšanas pārbaudiet tā atbalstu un atgriešanas formātu; tas nav tiešs vienas IPv4 virknes aizstājējs. Visbeidzot, neatkarīgi pārbaudiet iegūto pieprasījuma maršrutu. Pareiza biroja apakštīkla atpazīšana un paredzētā starpniekservera sasniegšana ir divi atsevišķi rezultāti.