Зошто 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.