Miért választja a PAC-fájlja a rossz hálózati adaptert

A laptop az irodai Wi-Fi-n van, az Ethernet-kábel csatlakoztatva van, és egy VPN-adapter is jelen van. A PAC-fájlja megkérdezi a myIpAddress()-t, melyik hálózaton van. Ez ésszerűnek hangzik, amíg olyan címet nem kap, amely a rossz adapterhez tartozik.

A hiányzó részlet az, hogy a függvény egyetlen címet ad vissza. Nem minden interfész leltára, és nem lép kapcsolatba webhellyel, hogy felderítse a nyilvános IP-címét. A magáncím, vagy akár egy loopback-tartalék sem mondja meg, melyik kilépési címet fogja használni a proxyn keresztüli kérés.

Egy válasz egy többcímes gépnek

A hálózati interfész kiválasztása a PAC-implementációhoz tartozik. A Windows-adapterek átrendezésére vonatkozó régi tanács egy adott böngésző- és operációsrendszer-verziót írhat le, de rossz általános megoldás. A Chromium dokumentálja a saját kiválasztási algoritmusát és többhálózatos korlátait; egy másik kliensnek nem kell ugyanazt a választást meghoznia.

Kezdje azzal, hogy azonosítja az érintett böngésző által ténylegesen szolgáltatott értéket, majd hasonlítsa össze a szkriptjében lévő alhálózati ellenőrzésekkel. Tegye ezt külön Wi-Fi-n, Etherneten és a jóváhagyott VPN-kapcsolaton. Egy meglepőnek tűnő cím még megfelelhet az implementáció szabályainak.

Tegye a döntést kevesebb találgatástól függővé

Ahol gyakorlatias, a proxyt a cél gazdagépneve alapján válassza, ne egy feltételezett kliensinterfész alapján. Ha hálózatfelderítés szükséges, használjon szándékos, dokumentált jelet, amelyet a szervezete irányít. A DNS-alapú felderítésnek is vannak hibamódjai, ezért határozza meg, mi történik, ha ez a jel nem érhető el.

Egyes implementációk myIpAddressEx()-t kínálnak. Elfogadása előtt ellenőrizze a támogatását és a visszatérési formátumát; nem közvetlen helyettesítője egyetlen IPv4-karakterláncnak. Végül önállóan ellenőrizze az eredményül kapott kérésútvonalat. Az irodai alhálózat helyes felismerése és a tervezett proxy elérése két külön eredmény.