De ce fișierul tău PAC alege adaptorul de rețea greșit

Laptopul este pe Wi-Fi-ul biroului, cablul Ethernet este conectat și un adaptor VPN este încă prezent. Fișierul tău PAC întreabă myIpAddress() în ce rețea se află. Sună rezonabil până când primește o adresă care aparține adaptorului greșit.

Detaliul lipsă este că funcția returnează o singură adresă. Nu este un inventar al tuturor interfețelor și nu contactează un site web pentru a descoperi IP-ul tău public. O adresă privată, sau chiar o soluție de rezervă loopback, nu îți spune ce adresă de ieșire va folosi o cerere prin proxy.

Un singur răspuns pentru o mașină cu mai multe adrese

Selecția interfeței de rețea aparține implementării PAC. Vechea recomandare de a reordona adaptoarele Windows poate descrie o anumită versiune de browser și de sistem de operare, dar este o soluție universală slabă. Chromium își documentează propriul algoritm de selecție și limitările cu mai multe rețele; un alt client nu trebuie să facă aceeași alegere.

Începe prin a identifica valoarea pe care browserul afectat a furnizat-o efectiv, apoi compară-o cu verificările de subrețea din scriptul tău. Fă acest lucru separat pe Wi-Fi, Ethernet și conexiunea VPN aprobată. O adresă care pare surprinzătoare poate totuși respecta regulile implementării.

Fă decizia să depindă de mai puține presupuneri

Acolo unde este practic, alege proxy-ul după numele gazdă al destinației în locul unei interfețe de client presupuse. Dacă detectarea rețelei este necesară, folosește un semnal deliberat și documentat pe care organizația ta îl controlează. Detectarea bazată pe DNS are și ea moduri de eșec, așa că definește ce se întâmplă când acel semnal nu este disponibil.

Unele implementări oferă myIpAddressEx(). Verifică suportul și formatul de returnare înainte de a-l adopta; nu este un înlocuitor direct pentru un singur șir IPv4. În final, verifică independent ruta cererii rezultate. Recunoașterea corectă a subrețelei biroului și atingerea proxy-ului dorit sunt două rezultate separate.