Можете да напишете PAC правило што наутро враќа едно прокси, а подоцна друго. Но од тоа правило не можете да заклучите дека секоја постоечка врска на прелистувачот го менува излезот напладне.

Функции како timeRange() учествуваат во одлуката за рутирање. Тие не се позадински планер што затвора тунели, преместува сокети или бара од давателот на прокси да ја ротира својата јавна IP.

Држете три настани одделно:

  1. Прелистувачот го оценува PAC и добива маршрута.
  2. Клиентот воспоставува или повторно користи врска според своите мрежни правила.
  3. Избраната услуга ја избира јавната адреса за својата понатамошна врска.

Временскиот услов директно се однесува на првиот настан. Веќе активно преземање или долготрајна врска е друга работа. Кеширањето на клиентот и повторното користење врски исто така значат дека 'скриптата содржи проверка на часовник' не е доволен доказ за точен распоред на префрлање.

Ако задача бара нов излез за секоја сесија, барање или временско прозорец, користете интерфејс дизајниран за тоа барање и проверете го неговото документирано однесување. PAC може да избира меѓу крајни точки, но не одредува што тие крајни точки прават со своите излезни адреси.

Рутирањето засновано на време сè уште може да биде корисно за намерна мрежна политика. Опишете го како избор на маршрута при оценување, не како гарантиран механизам за ротација на IP.

Поврзани статии