Når tidsbaserede PAC-regler vælger en proxy
En tidsregel i en PAC vælger en proxy, når routing evalueres. Den lover ikke at flytte en eksisterende forbindelse til en ny udgang på et præcist sekund.
Du kan skrive en PAC-regel, der returnerer én proxy om morgenen og en anden senere. Men du kan ikke udlede af den regel, at hver eksisterende browserforbindelse skifter udgang ved middagstid.
Funktioner som timeRange() deltager i en routingbeslutning. De er ikke en baggrundsplanlægger, der lukker tunneller, flytter sockets eller beder en proxyudbyder om at rotere sin offentlige IP.
Hold tre hændelser adskilt:
- Browseren evaluerer PAC'en og får en rute.
- Klienten opretter eller genbruger en forbindelse efter sine netværksregler.
- Den valgte tjeneste vælger den offentlige adresse til sin videre forbindelse.
Tidsbetingelsen vedrører direkte den første hændelse. En allerede aktiv download eller langvarig forbindelse er en anden sag. Klientcaching og genbrug af forbindelser betyder også, at 'scriptet indeholder et urtjek' ikke er tilstrækkeligt bevis for en præcis skifteplan.
Hvis en opgave kræver en ny udgang pr. session, anmodning eller tidsvindue, skal du bruge en grænseflade designet til det krav og verificere dens dokumenterede adfærd. En PAC kan vælge mellem endpoints, men den definerer ikke, hvad disse endpoints gør med deres egne udgangsadresser.
Tidsbaseret routing kan stadig være nyttig til en bevidst netværkspolitik. Beskriv det som at vælge en rute på evalueringstidspunktet, ikke som en garanteret IP-rotationsmekanisme.