Калі проксі адхіляе User-Agent APT
Распазнавайце яўную адмову па палітыцы ідэнтычнасці кліента, калі curl спраўляецца, а APT блакуецца праз той жа проксі.
curl атрымлівае URL. APT, выкарыстоўваючы той жа проксі, атрымлівае старонку з паведамленнем, што яго User-Agent не ўхвалены. Гэты адказ ужо звужае расследаванне: пасрэднік прымяняе палітыку кліента.
Адначасовая змена люстэркаў рэпазіторыя, пароляў і DNS знішчае гэтыя карысныя доказы. Захавайце атрыманы статус і адпаведны тэкст адмовы перад зменай маршруту.
APT дакументуе Acquire::http::User-Agent для метаду атрымання HTTP. Калі аператар сеткі патрабуе ўхвалены ідэнтыфікатар, задайце ўзгодненае значэнне свядома. Капіраванне поўнага радка ідэнтычнасці браўзера са старога адказу можа схаваць фактычны абнаўляльнік і ўсё роўна не выканаць іншую ўмову палітыкі.
Праверце межы няўдалага запыту. Запыт да HTTP-рэпазіторыя і HTTPS-тунэль паказваюць звычайнаму проксі без перахопу розную інфармацыю. Не рабіце выснову, што палітыка загалоўка, бачная на адным шляху, аўтаматычна прымяняецца гэтак жа ўнутры шыфраванага трафіку.
Старонка адмовы, вернутая там, дзе чакаліся метаданыя рэпазіторыя, можа пазней выклікаць памылку разбору або памылку, падобную да памылкі подпісу. Прачытайце крыніцу адказу перад зменай даверу да рэпазіторыя. Паспяховая маршрутызацыя праз проксі не робіць HTML-старонку палітыкі сапраўдным індэксам пакетаў. Для Hash Sum mismatch трымайце чаканую кантрольную суму і фактычныя байты разам.