Защо 403 от сайт с VPN не е повреда на прокси

Потребителите изключват VPN, получават 403 на вътрешен сайт и съобщават, че проксито е счупено. Три отделни неща могат да създадат тази страница: произходът е отказал заявката, предното прокси е отказало да отвори тунела или проксито е поискало собствените си идентификационни данни. Всяко от тях е правилен отговор на различен въпрос и сливането им в една обща страница за повреда унищожава единственото доказателство, което имате. Подредете отказа по компонента, който го е създал, и след това сравнете мрежовия път, който всеки компонент всъщност използва.

Назовете компонента, който е създал 403

HTTP кодът за състояние принадлежи на страната, която го е изпратила. Когато произходът върне 403, той е анализирал заявката и е решил, че извикващият може да не притежава ресурса, което е отговор за оторизация, а не транспортен проблем. Когато предно прокси отговори с 403 на CONNECT, то е отказало да изгради тунела изобщо и нищо по-нагоре не е било засегнато. Когато отговори с 407, то иска собствените си идентификационни данни, които нямат нищо общо с влизането в приложението.

RFC 9110 определя тези роли, включително предизвикателството, специфично за прокси. Прочетете собствения статус на отговора и всеки заглавен ред Proxy-Authenticate, преди да четете тялото, защото приятелска HTML страница за грешка обикновено скрива кой компонент я е написал.

Какво крие тунелът CONNECT от релей за байтове

След като прокси върне 200 на CONNECT, то препредава байтове и браузърът поддържа собствена TLS сесия с произхода. Затова прокси, което препредава байтове, не може да прочете криптирания 403 в тази сесия и никога не става автор на отказа. Отказът преди отварянето на тунела е напълно различно събитие, създадено с един слой по-ниско.

Обратно прокси, което прекратява TLS, е в различно положение: то притежава границата на TLS, анализира HTTP и може законно да пренаписва или прихваща отговори. Тази способност е избор на конфигурация, а не свойство на проксирането като цяло, и не дава право да се заобикаля политиката за достъп на приложението. Четенето на отговора е възможност; решението какво може да види извикващият остава работа на произхода.

Практическото следствие е, че трябва да знаете коя от трите форми използвате, преди да тълкувате 403. Добавянето на правила за HTTP инспекция към потоково прокси не му дава видимост, а очакването релей за байтове да обясни отказ на произхода ще ви изпрати да търсите в грешния журнал.

Сравнете изходния път на проксито с адреса на тунела на браузъра

Браузър, свързан с VPN, не премества автоматично отделен прокси сървър в този тунел. Произходът вижда изходния адрес на проксито и ако проксито все още излиза през локалния маршрут по подразбиране, защитеният сайт вижда адрес, който никога не е бил настроен да се доверява. Вътрешният VPN адрес на лаптопа е невидим за този произход. Това е най-честата причина работещ тунел да дава 403 от сайт, който се държи правилно за всички останали.

Тествайте двата пътя отделно, за да не се объркат адресите.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Първата заявка показва какво произходът отговаря за вашия собствен адрес, втората — какво отговаря за адреса на проксито. Съвпадаща двойка 403 сочи към правилата за оторизация на произхода; 200, последван от 403, сочи към пътя на проксито. Попитайте собственика на произхода кои адреси на източника наборът от правила всъщност допуска, вместо да предполагате, че VPN пулът е включен.

Тествайте всяка граница със заявка, която я изолира

Изолирайте слоя на проксито, като го помолите за нещо, което не може да откаже по причини от приложението. CONNECT към хост, до който проксито има достъп, с изхвърлен изход, ви казва дали допускането до тунела работи изобщо.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Ако това отпечата 200 за CONNECT и след това TLS ръкостискане, допускането на проксито е наред и по-късният 403 е дошъл от произхода. Ако отпечата 407, подайте идентификационни данни за проксито с --proxy-user и повторете, преди да правите каквото и да е заключение за сайта. Ако отпечата 403 на реда CONNECT, собственият списък за разрешаване на проксито е границата за изследване и приложението не участва.

Дръжте идентификационните данни извън историята на обвивката и извън поставените транскрипти. Парола за прокси, въведена в команден ред, е видима за други локални потребители, а прихванат CONNECT запис с идентификационни данни е по-лош от липса на запис.

Пазете присъдата четлива, вместо да пренаписвате страницата

След като знаете кой компонент е отказал, запазете този отговор. Обратно прокси, което преименува 403 от произхода като изчакване 504 или го заменя със страница за успех, скрива решение за оторизация зад история за наличност и изпраща следващия отговарящ в грешния екип. Персонализираните страници за грешка са добри, когато запазват статуса и добавят контекст.

Кеширането заслужава същото внимание. RFC 9111 урежда как споделените кешове могат да използват повторно отговори и отказ, създаден за един извикващ, не трябва да се предава на друг като разрешение. Ако отговорите за отказ изобщо се съхраняват, дръжте ги частни и ограничени и никога не добавяйте публично правило за свежест само за да намалите трафика нагоре.

Завършете с писмена присъда, която назовава компонента, статуса, който е създал, и адреса на източника, който произходът е видял. Запишете точната заявка, действащите настройки на проксито и часа, за да може следващият доклад да бъде съпоставен със същите доказателства, вместо да се извежда от паметта. Този запис отговаря на следващия доклад за секунди и спира същият 403 да бъде диагностициран отново като прекъсване на VPN.